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^ (54) Title: METHOD AND SYSTEM FOR VIRTUAL PROTOTYPING 

\o 

(57) Abstract: An integrated design environment (IDE) is disclosed for forming virtual embedded systems. The IDE includes a 
design language for forming finite state machine models of hardware components that are coupled to simulators of processor cores, 
preferably instruction set accurate simulators. A software debugger interface permits a software application to be loaded and executed 
on the virtual embedded system. A virtual test bench may be coupled to the simulation to serve as a human-machine interface. In one 
embodiment, the IDE is provided as a web-based service for the evaluation, development, and procurement phases of an embedded 

^ system project IP components, such as processor cores, may be evaluated using a virtual embedded system. In one embodiment, 
a virtual embedded system is used as an executable specification for the procurement of a good or service related to an embedded 

^ system. 
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METHOD AND SYSTEM FOR VIRTUAL PROTOTYPING 



5 [0001] This application claims priority from U.S. Provisional Application Number 

60/208,900, entitled "Method and System For Online Virtual Prototyping," filed June 2, 2000, 
and U.S. Provisional Application Number 60/230,171, entitled 'Method and System For 
Online Virtual Prototyping With Walkthrough Function," filed September 1, 2000. The entire 
contents of U.S. Provisional Application Nos. 60/230,171 and 60/208,900 are hereby 
1 0 incorporated by reference in their entirety. 

Background of the Invention 

1. Field of the Invention 

[0002] The present invention relates generally to computer implemented electronic 

design automation techniques to evaluate, design, and simulate embedded systems. More 
1 5 particularly, the present invention is directed towards the use of computer implemented 

techniques for the evaluation of Intellectual Property components used in embedded systems, 
the design of embedded systems, and tie procurement of goods and services related to an 
embedded system. 

2. Description of Background Art 



20 



[0003] There is increasing interest in embedded systems. An embedded system is a 

specialized computer system that is typically part of a larger system or machine. An 
embedded system requiring custom software is also sometimes described as a "platform." 



WO 01/95161 



PCT/US01/17873 



Embedded systems are used in industrial control systems, consumer products (e.g., mobile 
phones and computer game consoles), and telecommunication systems. 

[0004] An embedded system may include its own operating system or, in some cases, a 

single computer program. An embedded system commonly includes one or more 
5 microprocessors, peripheral hardware to perform input/output functions, and several software 
layers (e.g., device drivers, middleware, or applications). An embedded system having all of 
the hardware and software residing on a single chip is sometimes called a system on a chip 
(SOC). However, an embedded system can also be implemented as one or more printed circuit 
boards with the hardware components implemented as discrete integrated circuit chips. 

10 [0005] Embedded system design includes the design of both hardware and software 

that must work together in the final product Typically, the task of designing an embedded 
system is divided into the separate but complementary tasks of designing the hardware and the 
software, what is called the "hardware partition" and the "software partition The design of 
the hardware partition is facilitated by using as many commercially available hardware 

1 5 components as practical. In particular, the design of an embedded system is increasingly 
characterized by the use of pre-designed intellectual property (IP) components. An IP 
component (sometimes also known as an "IP block") is commonly used to describe a 
component of an embedded system that is licensed to others as intellectual property. 
However, the term DP component is also sometimes used by engineers, to describe a portion of 

20 an embedded system that is available from others. For example, a variety of companies 
license designs for a processor core. Thus, an embedded system designer may select a 
processor core suitable for an intended application and then design the remaining hardware 
(e.g., peripherals and buses) to implement the hardware portion. It is common for at least one 
portion of the hardware to be customized for a particular project. The software partition of an 

25 embedded systems project may use portions of software applications from other projects. 

However, typically a significant amount of code must be written for the software partition of a 
particular project 



2 
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[0006] FIG. 1 illustrates an exemplary embedded system design project 1 00 that may 

be divided into sequence of project phases. Exemplary times common for each phase are 
included on the left-hand side of the illustration. In a requirement definition phase 102, a set 
of requirements 1 04 is developed for a product idea 101. Key IP components must then be 
5 evaluated for possible use in the embedded system. Because of the nature of embedded system 
design, documentation alone is typically insufficient to understand how an IP component, such 
as a processor core, will function with a software application running user code. 
Consequently, the initial evaluation phase 106 may last up to several months in order to have 
sufficient time to identify useful IP components and to physically test the operation of 
1 0 software in a working test platform. 

10007] FIG. 2 is a flow chart showing in more detail some of the elements of a 

conventional evaluation phase 106. For the case of processor cores, this has conventionally 
involved identifying potential suppliers 202, contacting suppliers to request information 204, 
ordering and reviewing product information 206, ordering and purchasing an evaluation board 

15 208, receiving the evaluation board, 210, installing the evaluation board 212, installing 

software development tools 214, customizing the evaluation board 216, running evaluation 
software on the test board 218, and selecting suppliers 220. Note that the supplier must also 
commit significant resources to provides services to prepare and send product information 222, 
receiving orders 224, processing orders 226, and shipping evaluation boards 228. 

20 Additionally, support must be provided to users to use the evaluation boards (not shown in 
FIG. 2). The resources that a vendor must devote also include the resources to design, 
manufacture, and keep in stock a supply of evaluation boards. In some cases, a significant 
time delay may be involved for a vendor to arrange for evaluation boards having custom 
silicon and printed circuit boards to be designed and manufactured. Moreover, each 

25 evaluation board may have a significant cost (e.g., thousands of dollars) such that a vendor 
will only maintain in stock a limited number of evaluation boards at any one moment of time. 
Consequently, in some cases embedded system designers may have to wait substantial periods 
of time to obtain an evaluation board. 
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[0008] From the standpoint of the embedded system designer, the evaluation phase 106 

is a time consuming and costly process, particularly if a significant number of IP blocks from 
different vendors are to be evaluated. Conventionally, evaluating IP blocks from different 
vendors requires evaluating the operation of separate evaluation boards for each IP block. In 
5 addition to being a time consuming process, each EP block can be evaluated only in isolation, 
which can make it difficult to determine how several IP blocks would interact together in a 
single embedded system. From the perspective of the IP vendor this is a costly marketing tool 
that requires IP vendors to invest in creating standard test board platforms (e.g., boards 
including reference peripheral devices and driver applications). The cost to the BP vendor 
10 includes the cost of the evaluation boards and the support services that must be provided for » 
potential customers to successfully evaluate each board. 

[0009] After key IP components are selected, a development phase 1 10 begins, which 

commonly lasts 3-9 months. The development phase 1 1 0 commonly begins by defining the 
architecture 108 of the embedded system, with the system architecture including, for example, 
1 5 the processors) to be used, hardware peripherals, and user interfaces. The hardware 
architecture may be used to form an initial partition of the hardware and software. 
Conventionally, hardware development 1 12 proceeds faster than software development 1 14 
because software developers need a hardware implementation to develop some types of 
software. 

20 [0010] FIG. 3 is a flow chart showing in more detail some of the aspects of the 

development phase 110. After the system architecture is defined 108, specification documents 
302 for both the hardware and the software partition are created. The hardware development 
begins by developing hardware components 304. Software engineers tnay use an evaluation 
board to develop some of the software application layers 352 but cannot start developing 

25 certain types of software (e.g., middleware and device drivers) until a hardware emulation 
prototype 308 is available. Other steps common in the subsequent hardware and software 
development are indicated on FIG. 3. Typically, the hardware must reach a high level of 
implementation detail before a hardware emulator having sufficient speed may be developed 
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306 for continued software development 354 (e.g., middleware, device drivers) to proceed. 
The hardware partition is commonly emulated using hardware emulation boards and hardware 
acceleration boxes, which feature a combination of re-programmable hardware, typically in the 
form of Field Programmable Gate Arrays (FPGA), and plugable modules/boards containing 
5 the processors) that will emulate the hardware partition. 

[0011] Hardware emulators are commonly a factor of 100 or more slower than the final 

physical system but provide sufficient speed to debug software. Unfortunately it may take up 
to two-thirds of the development cycle before the hardware implementation reaches a high 
level of implementation detail and a physical hardware emulator 308 is configured. This 

10 means that feedback 356 to refine hardware components 3 10 comes later than desired. 

Moreover, early software integration 358 must wait until hardware components have been 
fabricated 312 and a PCB prototype designed 314 and fabricated 316. After the results of the 
early PCB prototype 360, hardware development proceeds 318, 320, 322, and 324 towards a 
final PCB prototype upon which final software integration and testing 360 may be performed. 

15 Note that FIG. 3 assumes that hardware emulator is used. However, a conventional hardware 
emulator is comparatively expensive. In some embedded system projects a hardware emulator 
(e.g., a FPGA hardware emulator) may not be cost effective such that much of the software 
development and integration must wait until a physical prototype is available. 

[0012] Referring again to FIG. 1 , note that the procurement of many goods or services . 

20 required for the manufacture of an embedded system often must wait until a tested prototype 
120 is available after a quality assurance and testing phase 118. Procurement significantly 
earlier than the tested prototype stage 120 is typically impractical because there is an 
insufficient quantity and quality of documentation prior to the tested prototype stage that 
would permit procurement needs to be adequately communicated with vendors. The 

25 procurement phase 122 may include purchasing components, PCB boards, DP licenses, and 
arranging for semiconductor fabrication of custom silicon chips required for a manufacturing 
and assembly phase 126 to produce a final product 128 based on a pre-product definition 124. 
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[0013] Embedded systems designers are under increasing pressure to reduce the time 

to market and to increase the software functionality of embedded systems, which in turn tends 
to increase the complexity of embedded system software. Embedded system design projects 
would be facilitated if there were a computer aided design tool that permitted the efficient 
5 selection of a processor core or other IP components, facilitated the co-design of both the 
hardware and software partition, and facilitated the procurement of IP components and other 
necessary services. However, conventional automated design tools have serious shortcomings 
that limit their usefulness in the design cycle, particularly for embedded systems executing 
complex software applications. Moreover, conventional automated design tools also have 
10 shortcomings in speed, user-friendliness, and security that have hindered the development of 
web-based design tools. 

[0014] One drawback of conventional electronic design approaches for embedded 

systems is that they are hardware-centric and typically have an execution speed that is too slow 
for the simulation to serve as a hardware emulator for the purposes of debugging software. 
15 For example, one conventional electronic design method is to use a hardware definition 
language (HDL) to model the hardware partition at the hardware implementation level. 
However, modeling the hardware implementation in HDL requires that the hardware be 
extensively developed (e.g., fully detailed) before the software, which can require a significant 
length of time in the development cycle. 

20 [0015] In addition to its other problems, a HDL simulation (e.g., one using a cycle- 

accurate processor model and a detailed implementation model of hardware) has such a high 
level of implementation detail that a software application executed on HDL simulation of the 
hardware partition would be too slow for meaningful software debugging during a typical 
development phase. As one example, a software application running on virtual hardware 

25 needs a comparatively high execution speed to detect deadlocked situations between multiple 
on-chip processors. As another example, a software application running on virtual hardware 
needs a comparatively high execution speed to perform a booting test of a full-fledge operating 
system (OS) on the hardware being designed. However, HDL models typically execute at too 
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slow a speed to permit a software designer to evaluate the system aspects in which a software 
designer is interested. 

[0016] A further drawback of HDL models is that it is often impractical to share them 

with third parties that are not legally bound to maintain the confidentiality of the model. An 
5 HDL description of an embedded system includes implementation details required to fabricate 
an end product. HDL models have such a high level of implementation detail that companies 
are reluctant to share HDL models with other companies for fear of losing valuable proprietary 
trade secrets. As one consequence, IP vendors typically do not provide HDL models of their 
products for evaluation. Another consequence is that embedded system designers and IP 
10 vendors typically do not make HDL models of IP components and sub-systems available on 
the Internet 

[0017] The problems associated with conventional embedded system design projects 

can be anticipated to become worse as improvements in the processing power of embedded 
systems permits embedded systems having more complex software applications. This can be 

1 5 expected to increase the need to rapidly and effectively evaluate IP blocks during the 

evaluation phase, to accelerate the pace of software development during the development 
cycle, and to improve the procurement of goods and services related to the embedded system 
project, including the licensing of IP blocks. However, conventional automated design tools 
do not provide the right level of abstraction, quick model creation, ease of use, execution 

20 speed, and understandability to permit substantial improvements in the evaluation, 
development, and procurement phases of an embedded system design project. 

[0018] What is desired is a computer-aided system and method for improving the 

evaluation, development, and procurement phases of an embedded system development 
project. 



25 
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[0019] An integrated design environment (IDE) is disclosed for simulating embedded 

systems. The IDE includes a graphical user interface and a design language for forming finite 
state machine models of hardware components that are coupled to processor simulators, 
preferably instruction set accurate simulators of processor cores. In one embodiment, the 
5 design language has graphical symbols adapted from the specification design language, is 
configured to reduce simulation overhead, and also includes features for modeling the signals 
of hardware elements. A virtual test bench may be coupled to the simulation to serve as a 
human-machine interface for interacting with the simulation. In one embodiment of virtual 
test bench, the virtual test bench includes a graphical representation of a user input interface 

1 0 and a graphical representation of an output display. A software debugger permits software to 
be loaded and executed for the simulation. In a preferred embodiment, the software debugger 
is adapted to permit at least one binary program code of a software application compiled for a 
target processor to be loaded by a user and executed on the virtual embedded system. One 
application of the IDE is to form a virtual embedded system having an execution speed 

1 5 sufficiently high to permit the evaluation of benchmark software executing on the virtual 

embedded system. In one embodiment, a virtual embedded system emulates the function of a 
physical evaluation board so that a virtual embedded system may be used to evaluate 
components of an embedded system, such as a processor core, in an evaluation phase of an 
embedded system project Another application of the IDE is to form a virtual prototype of an 

20 embedded system having an execution speed sufficiently high to permit the virtual prototype 
to be used to develop software. In a preferred embodiment, a user may execute production 
quality embedded system code on the virtual prototype. In one embodiment, a virtual 
prototype is used during a development phase of an embedded system project to develop 
software. Still another application of the IDE is to form a virtual prototype that may be used 

25 as a design specification. In one embodiment, the virtual prototype is used as design 
specification to coordinate the actions of hardware and software developers during a 
development phase of an embedded system project. In another embodiment, the virtual 
prototype is used as a design specification for the procurement of a good or service related to 
the embedded system. 
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[0020] The IDE may be hosted on a network server accessible from a client computer. 

In one embodiment a persistent virtual channel may be formed between the client computer 
and the network server for executing the DDE on the network server. In one embodiment, a 
user may use the IDE to create a design and store executable files associated with the design in 
5 a design repository. In one embodiment of a collaborative method of designing embedded 
systems, an administrator may grant access privileges to the design to members of a user 
group. In one embodiment, designs of embedded systems or sub-systems are stored in a 
library and made accessible to other users. Additionally, in one embodiment a vendor of a 
component for an embedded system may design and store executable files of virtual embedded 
10 systems for demonstrating the operation of the component in a library coupled to the network 
server. 

[0021] In one embodiment, the network server is coupled to the Internet, permitting the 

IDE to be offered as a web-hosted service. An on-line bulletin board may be coupled to a 
server for hosting designs. In one embodiment, the on-line bulleting board includes a bidding 
1 5 board for a vendor to access a design published by a designer on the bidding board. In a 

preferred embodiment, a designer may select the access privileges of vendors to the design. In 
a preferred embodiment, a vendor may receive a request for quote that includes access 
privilege to the design. 

[0022] In one embodiment of a web-based service for providing evaluation services, 

20 one or more virtual embedded systems for evaluating components of an embedded system are 
stored in a library coupled to a web server. Users may select a virtual embedded system, 
modify the virtual embedded system, and run a simulation of the embedded system. In a 
preferred embodiment the on-line behavior of users is recorded to form data on the usage of 
the virtual embedded systems. The usage behavior may be converted into marketing data, 
25 such as data on preferred processor cores and hardware peripherals. 

[0023] The features and advantages described in the specification are not all-inclusive, 

and particularly, many additional features and advantages will be apparent to one of ordinary 
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skill in the art in view of the drawings, specification, and claims hereof. Moreover, it should 
be noted that the language used in the specification has been principally selected for 
readability and instructional purposes, and may not have been selected to delineate or 
circumscribe the inventive subject matter, resort to the claims being necessary to determine 
5 such inventive subject matter. 

Brief Description of the Drawings 

[0024] FIG. 1 is a flow chart showing a conventional embedded system design cycle. 

[0025] FIG. 2 is flow chart showing in more detail the evaluation phase for the 

conventional embedded system design cycle of FIG. 1 . 

10 [0026] FIG. 3 is a flow chart showing in more detail a conventional hardware/software 

development phase for the conventional embedded system design cycle of FIG. 1 . 

[0027] FIG. 4A is a block diagram of major software modules of an integrated design 

environment (IDE) and FIG. 4B is an illustrative figure of applications for the IDE. 

[0028] FIG. 5 is a flow chart showing a preferred method of designing an embedded 

1 5 system in accordance with the integrated design environment of the present invention. 

[0029] FIG. 6 is a detailed flow chart of a preferred method of evaluating intellectual 

property for the design method of FIG. 5. 

[0030] FIG. 7 is a detailed flow chart of a preferred method of hardware/software 

development for the design method of FIG. 5. 
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[0031] FIG. 8 is a detailed flow chart of a preferred method of procurement for the 

design method of FIG. 5. 

[0032] FIG. 9 is a conceptual block diagram of an integrated development environment 

for designing virtual prototypes of embedded systems. 

5 [0033] FIG. 1 0 illustrates the formation of an object file of a hardware description for a 

discrete event simulation engine. 

[0034] FIG. 1 1 is an illustration of the architecture of an integrated design 

environment. 

[0035] FIG. 12 is a top level flowchart of the a method of using the integrate design 

10 environment. 

[0036] FIG. 13 is a flow chart of a sub-task of FIG. 12. 

[0037] FIG. 14 is a flow chart of a sub-task of FIG. 12 for simulation and debugging. 

[0038] FIG. 1 5 is a screen shot of an DDE design window, showing the details of a 

finite state machine representation using graphical constructs. 

1 5 [0039] FIG. 1 6 shows examples of a block construct having a process, devices, and a 

declaration constructs. 

[0040] FIG. 1 7 A shows a conventional finite state machine representation of a 

hardware peripheral in a transition condition/action format 
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[0041] FIG. 17B shows the finite state machine of FIG. 17A written using graphical 

constructs in accord with the present invention. 

[0042] FIG. 18 shows two communicating finite state machines with implicit signal 

queues explicitly drawn. 

5 [0043] FIGS. 19A and 19B are a table showing graphical objects of a preferred design 

language. 

[0044] FIG. 20 is a screenshot showing an example of a finite state machine 

representation of a hardware counter peripheral. 

[0045] FIG. 21 is a screen shot of a main window of a preferred design window and 

10 toolbars. 

[0046] FIG. 22 is a screen shot showing a preferred standard toolbar for the integrated 

design environment. 

[0047] FIG. 23 is a screen shot of a preferred navigation and symbol editor toolbar. 

[0048] FIG. 24 is a screen shot of a preferred toolbar for forming finite state machine 

1 5 representations of hardware components. 

[0049] FIG. 25 is a screen shot of a preferred compiler debugger toolbar. 

[0050] FIG. 26 is a screenshot of a preferred testbench builder toolbar. 

[0051] FIG. 27 is a screen shot of a message window showing different message tabs, 

and the status bar. 
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[0052] FIG. 28 is a screen shot of a base station for a cordless handset showing the 
top-level block diagram opened in the design window. 

[0053] FIG. 29 is a screen shot of a processor with an interrupt controller and a counter 
peripheral. 

5 [0054] FIG. 30 shows screenshots of a preferred design, signal, and connectivity 
browser. 

[0055] FIG. 3 1 is a screenshot of the design browser showing details of a library 
browser. 

[0056] FIG. 32 is a screen shot of a project library manager window. 

1 0 [0057] FIG. 33A is a screen shot of a waveform viewer tool for viewing signal 

occurrences and values of variables on a time axis. 

[0058] FIG. 33B is a second screen shot of a waveform viewer tool. 

[0059] FIG. 34A is a screen shot showing a test bench editor window (right), and a test 

bench control library (left). 

1 5 [0060] FIG. 34B is a screen shot of a virtual test bench. 

[0061] FIG. 34C is a screen shot of a virtual test bench. 

[0062] FIG. 35 is an illustrative diagram of the operation of a simulation cockpit. 
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[0063] FIG. 36A is a screen shot showing the execution of a simulation with multiple 

windows opened. 

[0064] FIG. 36B is an illustrative screen shot showing an opened software debugger 

interface superimposed over an embedded system design. 

5 [0065] FIG. 36C is an illustrative screen shot illustrating how a breakpoint of 

execution may be associated with a graphical construct of the finite state representation of the 
hardware components. 

[0066] FIG. 37 is a conceptual illustration of a processor integration interface. 

[0067] FIG. 38 is a screenshot of (he top-level diagram of a (ARM) processor and two 
10 peripherals. 

[0068] FIG. 39 is a screenshot of a processor IO Configurator Wizard. 

[0069] FIG. 40 is a detail of a screen shot of of the Processor IO Configurator Wizard. 

[0070] FIG. 4 1 is a block diagram of a client-server architecture and components for 

virtual prototyping. 

1 5 [0071] FIG. 42 is a block diagram of the client-server architecture and components for 

an Internet deployment of on-line virtual prototyping. 

[0072] FIG. 43 is a screenshot of a virtual prototyping window deployed through a 

web browser. 
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[0073] FIG. 44 is a diagram of a network architecture and software modules for 

collaborative design. 

[0074] FIG. 45 is a table of icons for a signal browser. 

[0075] FIG. 46 is a block diagram of a test bench coupled to a simulation. 

5 [0076] FIG. 47 is a flow chart showing how test bench controls and variables may 

negotiate a communication interface. 

[0077] FIG. 48 is a block diagram of an interactive walkthrough embodiment. 

[0078] FIGS. 49A-49J are screen shots of an interactive walkthrough of an embedded 

system. 

10 [0079] FIGS. 50-55 are screen shots of an example of an on-line embodiment. 

[0080] The figures depict a preferred embodiment of the present invention for purposes 

of illustration only. One of skill in the art will readily recognize from the following discussion 
that alternative embodiments of the structures and methods disclosed herein may be employed 
without departing from the principles of the claimed invention. 

1 5 Detailed Description of the PreferredEmbodiments 

[0081] The present invention generally includes a computer-implemented technique 

for simulating an embedded system using a graphical integrated development environment 
(IDE) design application that has features for rapidly creating and evaluating virtual embedded 
systems (also known as "virtual platforms" or "virtual prototypes" for new designs) and that 
20 has a sufficient simulation speed and test features to permit evaluation, development, and 
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debugging of an embedded system software application to be performed with a virtual 
embedded system. 

[0082] FIG. 4A is a block diagram illustrating major software modules of a preferred 

embodiment of the IDE 402. Further details on the interfaces coupling the software modules 
5 are described below in more detail. The software modules of IDE 402 may reside on a 
memory 450 of a computer 460 having a computer processor and memory, such as personal 
computer or computer coupled to a network server. It will also be understood that the IDE 402 
may be stored as a software application on a computer readable medium, such as a compact 
disk. 

1 0 [0083] The IDE 402 may be conceptually divided into a user design portion 482 and a 

simulation portion 486 that communicate with each other through process boundary 488. IDE 
402 preferably includes a graphical user interface (GUI) software module 420 for a user to 
interact with IDE 402. An editor and debugger module 470, design database module 472, 
code generator module 474, and compiler module 476 may be coupled to GUI software 

15 module 470 as a hardware design and modeling module 478 for forming a description of the 
hardware partition of an embedded system. 

[0084] A simulation loader module 422 invokes other IDE modules when a simulation 

of an embedded system is initiated from GUI module 420. A command input module 424 
receives commands from the GUI module 420 and passes them on to a command router 

20 module 426, which selects whether the command is routed to a scheduler processor simulator 
module 432, scheduler module 430, or simulation engine module 436. A message output 
module 428 communicates messages from the processor simulator module 432 and the 
simulation engine module 436 to GUI module 420. The scheduler module 430 coordinates the 
actions of the processor simulator module 432 and the simulation engine 436, providing global 

25 execution control for the virtual system. The processor simulator module 432 includes a 
processor simulator, preferably an instruction set accurate processor simulator, for each 
processor core in a library of processor cores and is configured to decode an instruction stream 
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residing in a virtual memory. As shown in FIG. 4A, several processor simulator modules 432 
may be included to support the simulation of more than one processor core. A processor 
simulator module 432 may have an associated slave component module 434 such as cache or 
memory model. The simulation engine module 436 provides simulation services to execute a 
simulation and is described below in more detail. As described below in more detail, in one 
embodiment the hardware description may include one or more dynamic link library files. 
Consequently, in this embodiment, component DLL modules 438 of the hardware description 
are dynamically loaded by the simulator loader. A simulation cockpit module 440 loads test 
bench controls and provides a simulation cockpit window for a user to interact with a virtual 
system. 

[0085] A software debugger module 442 provides a debugging interface with the 

processor simulator, allowing the soflware debugger module to control the execution of the 
processor simulator and perform other software debugger functions, such as displaying register 
values. In a preferred embodiment a software debugger permits embedded system software to 
be loaded for execution on the processor simulator of the virtual embedded system. In one 
embodiment, the software debugger is adapted to permit a user to load and execute binary 
program code of a software application compiled for a target processor. 

[0086] Referring to FIG. 4B, IDE 402 may also be part of a computer system having 

additional tools 405 and on-line technology 401 to provide a variety of services 403 related to 
the evaluation, development, and procurement phases of an embedded systems project. As 
illustrated in FIG. 4B, in one embodiment IDE 402 is used to provide services associated with 
the evaluation, development, or procurement phases of an embedded system project. These 
services may include intellectual property aggregation 404, procurement services 406, 
geographically distributed co-development 408, marketing of goods or services related to 
embedded systems 410, and evaluation of IP components (e.g., processor cores) 412. In one 
embodiment the services are offered as a web-based service with the IDE residing on a 
network server. However, it will be understood that some of the functions of a web-based 
service may be emulated by exchanging data files using other techniques, such as by shipping 
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executable files on a computer readable medium (e.g., a CD), making executable files 
available via a file transfer protocol (FTP) technique, or by sending data files via e-mail. 
Moreover, it will also be understood that the IDE may use to provide one or more services to 
other types of networks, such as a local area network, wide area network, intranets, or 
5 extranets. 

[0087] FIGS. 5-8 show methods of using the IDE of the present invention in an 

embedded system design project and FIGS. 9-49 show details of the IDE and its use. The IDE 
of the present invention has features for rapidly creating virtual embedded systems, which 
permit the virtual embedded systems to be used to evaluate the operation of an embedded 
10 system executing user code loaded onto the virtual embedded system. This permits embedded 
systems to be designed in new and more efficient ways. 

[0088] FIG. 5 is an illustrative flow chart of showing some of fee ways that the IDE 

402 of the present invention may be used in an embedded system design project, preferably as 
part of a web-based service. Illustrative times for the completion of each phase of an 

15 embedded system project are shown. As shown in FIG. 5, the evaluation phase 106 of an 
embedded system project may be improved by using the IDE of the present invention to 
provide virtual embedded systems ("virtual platforms") for evaluating intellectual property 
(IP) components 502, preferably as part of a web-based service. This leads to a reduction in 
the time required for evaluating IP components and/or allows larger numbers of IP 

20 components to be evaluated compared to the conventional approach of using physical test 
evaluation boards. As an illustrative example, an evaluation phase 106 that would 
conventionally require 1-3 months using physical evaluation test boards may be reduced to 
about 1-2 weeks using virtual embedded systems to evaluate IP components. 

[0089] FIG. 6 shows in greater detail some of the aspects of a preferred embodiment 

25 for providing an on-line evaluation service. Referring to FIG. 6, in one embodiment of the 
present invention the IDE 402 may be used during the evaluation phase 106 of an embedded 
system project to provide a simulation of an embedded system for evaluating IP components 



18 



WO 01/95161 PCT/US01/17873 



502, such as processor cores. The IDE and associated tools and services may be used to select 
models of IP components and virtual platforms 636, to customize virtual platforms 638, to 
load and execute benchmark software on the virtual platforms 642, and to evaluate the 
operation of the embedded system platform using virtual test benches 640 and debugging tools 
5 644. As described below in more detail particularly in regards to web-based embodiments, the 
use of virtual prototypes for evaluating IP components provides many benefits in terms of 
time, cost, and convenience for evaluating IP components compared with the conventional 
approach of using physical evaluation test boards and physical test hardware to evaluate IP 
components. 

10 [0090] Referring again to FIG. 5, the present invention may also be used to form a 

virtual prototype of an embedded system early in a development phase 1 10 of an embedded 
system project The virtual prototype can be used to evaluate and debug software before 
hardware implementation details are sufficiently developed to program a conventional FPGA 
hardware emulator. A conventional FPGA hardware emulator requires substantial hardware 

1 5 implementation details and may also require a significant physical set-up time, which typically 
makes the FPGA hardware emulator unavailable for software debugging for many months into 
the development cycle. Consequently, by using a virtual prototype for early software 
development, significant savings in time and/or improvements in software quality may be 
achieved. Thus, in the illustrative example of FIG. 5, the present invention permits a reduction 

20 of l-to-4 months in the development time compared with a conventional embedded system 
project relying upon FPGA hardware emulators such as that shown in FIG. 3 . Also, since a 
conventional FPGA hardware emulator is comparatively expensive, the present invention 
provides a substantial cost savings compared to a conventional FPGA hardware emulator. 

[0091] FIG. 7 is a more detailed flow chart of a method of using virtual prototyping in 

25 a development phase. Referring to FIG. 7, one aspect of the present invention is an IDE 402 
for rapidly developing a virtual prototype 704 of an embedded system early in the prototype 
phase 110 (e.g., after the architecture definition 108), with the virtual prototype 704 executing 
a software application with sufficient speed to permit the virtual prototype 704 to be used to 
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develop software early in the development phase 1 10 and to provide early feedback to 
hardware designers. 

[0092] As illustrated in FIG. 7, the hardware designers can begin to develop hardware 

components using the virtual prototype 704 as an executable specification. Correspondingly, 
5 the software developers may use the virtual prototype 704 for early software development 352 
(e.g., application layers, middleware, and device drivers), continued software development 354 
(e.g., middleware and device drivers), and for early software integration 358 (i.e., evaluating 
system-level operation of the embedded system with an early version of the final software). 
This can be used to provide early feedback 356 to hardware developers to refine the hardware 

10 components. Note also that if there are any flaws in the early PCB prototype 360 revealed 
during physical board testing 362 that the virtual prototype 704 may be modified and used for 
final software integration 370. Comparing FIG. 7 with the conventional approach of FIG. 3, it 
can be seen that seen that the use of a virtual prototype in accordance with the present 
invention may be used to accelerate the development of software development and integration, 

1 5 thereby beneficially reducing the time required for the development phase 1 1 0 and/or 
increasing the quality of the final embedded system. 

[0093] Referring again to FIG. 5, a virtual prototype 704 developed for the 

development phase 110 may also be used to improve the procurement process by using the 
virtual prototype as an executable functional specification in an early procurement phase 560. 

20 The virtual prototype may, for example, be used by a PCB board manufacturer, component 
distributor, semiconductor fabrication company, or other group 504 to understand the function 
of the embedded system at a high level of abstraction, i.e., from the viewpoint of major 
components, signals, and their interactions. Since an interactive virtual prototype may be 
created early in the development phase 1 10 before a tested (physical) prototype is available, 

25 several weeks or more may be saved compared to a conventional procurement phase. FIG. 8 
shows in more detail a preferred embodiment for using a virtual prototype as part of a 
procurement system for submitting request for quotes for goods or services related to an 

20 
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embedded system project. In a preferred embodiment, the procurement system may be part of 
a web-based service. 

[0094] FIG. 9 is a conceptual illustration of one embodiment of a graphical IDE 402 of 

the present invention. Referring to FIG. 9, processor simulators for one or more processor 
5 cores 902 are stored or accessible from a library of processors. In one embodiment, other IP 
components, such as models of hardware peripherals, may also be stored in a library 904. The 
IDE preferably includes a library having at least one IP block, including at least one processor 
simulator that a designer may select. The processor simulator is a model simulating the 
function of a processor core and, if desired, additional elements associated with the processor 

10 core. As described below in more detail, in a preferred embodiment, a processor core is 
modeled as a high speed instruction set accurate (ISA) simulator. A peripheral editor and 
discrete event simulator 906 is used to execute an object file of a hardware description 908. 
The hardware description is preferably created with graphical constructs in what the inventors 
call the "MAGIC-C" language. As illustrated in FIG. 9, the peripheral editor and simulator 

15 906 may include models of the hardware peripherals and busses, I/O modules, hardware 
accelerators, processor glue logic and custom IP. A test bench builder 910 permits a virtual 
test bench having a graphical interface emulating a human/machine interface to be displayed to 
a user. 

[0095] FIG. 10 shows a preferred embodiment of a discrete-event simulation engine 

20 1 002 for executing the simulation is optimized for system-level simulation at software 
execution speeds preferably exceeding millions of instructions per second. A hardware 
modeling environment (not shown in FIG. 10) is used to create a hardware specification from 
which an object file for the hardware specification 1004 may be compiled for execution on a 
discrete event simulation engine 1002. As described below in more detail, in a preferred 
25 embodiment, finite state machine representations of the hardware specification 1006 are 

created using graphical object "constructs" that have a graphical portion and a textual portion 
for defining their function. In one embodiment, the graphical constructs may include user- 
defined high level descriptions of task behavior (e.g., C/C++ models) and shapes adapted from 
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the specification and description language (SDL). Consequently, a graphical database 1010 
and behavior database 1012 is included to generate code for the hardware specification. As 
indicated in FIG. 10, a design editor 1008 accesses graphical constructs from a graphical 
database 1010. A user may input code describing the function or attributes of a graphical 
construct along with inputs/outputs to a graphical construct A code generator 1016 (e.g., a 
C++ code generator) and compiler 101 8 is used to generate an object file of the final hardware 
specification, that is linked in the simulation engine, resulting in a compiled code simulation 
executable. In another embodiment, separate dynamic link library (DLL) files may be 
generated for portions of the hardware specification (e.g., for each symbol or component) that 
are loaded at start-up by a simulation loader to form fee simulation. If desired, an export back- 
end APIs 1022 may be included to allow a user to traverse and access the internal design 
database. This enables users to build their own code generator 1024 for different languages 
(i.e., should language other than the preferred implementation in C++ be desired). 

[0096] FIG. 1 1 is a block diagram illustrating in more detail some of the operation of 

15 the discrete event simulation engine 1002. Referring to FIG. 1 1 , an open simulator 

Application Procedure Interface (API) 1 102 is preferably included to communicate memory 
transactions (i.e., read and write operations) from ISA simulators of processors 1 120 to the 
FSM peripheral models in one direction, and interrupts from the peripheral model to the 
processor model in the other direction. Additional APIs 1 104, 1 106 may be included for 
20 coupling a test bench to the discrete event simulation engine and for coupling a software 
debugger 1 130 to an instruction set accurate simulator of a processor. 

[0097] As shown in FIGS. 28, 29, and 37, the use of an instruction set accurate 

simulator to model a processor core permits the processor simulator to exchange memory 
transactions with the hardware partition and to receive interrupts from the hardware partition 
25 using APIs linking the hardware partition and the instruction set accurate simulator: A 

configuration to map address spaces from the virtual processor core to the virtual hardware is 
part of the IDE. One advantage of an instruction set accurate simulator is that it permits user 
binary program code (e.g., a binary program executable of a software application) to be 
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compiled for the target processor and to be loaded and executed by the processor simulator at a 
high rate of execution (e.g., 1-10 MIPS running the simulation on a computer system having a 
high speed microprocessor). This is fast enough for software developers to explore software 
issues of production quality code (e.g., software execution and debugging). For example, with 
5 the IDE running on a PC having a 450 MHz microprocessor, the simulation has a sufficient 
execution speed to boot a typical embedded system operating system (e.g., WINDOWS NT or 
LINUX) in less than 60 seconds, with less than 30 seconds being a typical booting time. As 
shown in FIGS. 1 1 and 36, APIs may be used to couple a debugger to the instruction set 
simulator. In one embodiment, a user may associated breakpoints of execution in the FSM 

10 representation of a hardware element and may select signals of the hardware partition for 
viewing in a waveform viewing. This improves the ability of a user to debug hardware and 
software. In one embodiment, the ability to set breakpoints and perform single-step debugging 
allows the designer to stop the entire system simulation at any point in either the software or 
hardware domain. A virtual test bench 1 120 may be coupled by an API 1 104 to the virtual 

1 5 hardware partition. 

[0098] Referring to FIGS. 12-13, in a preferred embodiment, the IDE permits a user to 

model hardware elements and processes as blocks, processes, or symbols. FIG. 12 is a flow 
chart 1200 of an exemplary design process for creating a virtual prototype 702, which includes 
designing a functional specification of an embedded system 1210, creating test benches 1220, 

20 generating code 1 230, and simulating and debugging the virtual prototype 1 240. FIG. 1 3 is a 
more detailed flowchart of some of the steps in the design process 1210 for creating FSM 
representations of blocks, processes, and symbols in the MAGIC-C language. FIG. 14 is a 
flowchart showing steps for setting breakpoints and debugging during the simulation and 
debugging of a virtual prototype 1240. In a preferred embodiment generated code contains 

25 extensive debugging hooks, allowing graphical debugging of FSM code and providing 
advanced debugging features as single-stepping and breakpoint placement directly on the 
graphical constructs, and this in the same Design editor window which was used to create the 
FSM specification. In one embodiment, the C source file implements the FSM model using a 
skeleton build around a single switch statement and a breakpoint macro that reports the state of 
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the FSM to be displayed during simulation and allow the placing of breakpoints and single - 
stepping. 

[0099] Referring to FIGS. 15-26, the IDE includes a graphical design editor having a 

design language to create an extended finite state machine (FSM) representation of hardware 
5 peripherals in the hardware partition. As shown in FIGS. 19A and 19B, in a preferred 

embodiment the design language is a graphical design language having graphical objects for 
forming a FSM representation as a series of linked objects representing the FSM. Referring to 
FIG. 15, in a preferred embodiment the graphical object symbols may be selected from a menu 
1 520, a textual portion of the object input by the user, and the graphical object connected to 

10 other graphical objects using connectors 1505. A preferred embodiment of a graphical design 
language, known as "MAGIC-C™, includes some features of the specification and description 
language (SDL) adapted to create a hardware description. Referring to FIGS. 21-26, in a 
preferred embodiment, a menu-driven graphical interface is used to fecilitate the creation of 
hardware peripherals. As shown in FIG. 21, the IDE preferably has a menu-driven graphical 

1 5 user interface that preferably includes a design window for creating a design with toolbars for 
accessing functions using a computer mouse or similar interface. The IDE preferably includes 
a peripheral design editor and simulator that is adapted to permit hardware IP components and 
processes to be created and linked with other IP components. 

[0100] In a preferred embodiment, FSM representations of hardware elements may be 

20 encapsulated into containers (symbols) having signal pins and connectors that may be labeled 
to facilitate a high-level functional block understanding of the embedded system but which 
may also be opened to reveal lower-levels of detail of each symbol or block. FIG. 28 shows an 
exemplary screen shot of a top-level block diagram of a cordless phone system showing a 
cordless phone symbol 2805 with pin symbols 2810. FIG. 29 shows an exemplary screen shot 
25 of a processor simulator 2905 coupled to an interrupt controller 2920 and a counter peripheral 
2930. Note that the memory read/write transactions from the pins for processor simulator 2905 
to counter 2930 may be labeled as well as interrupt signals from the interrupt controller 2920 to 
the processor simulator 2905 . Consequently, a high-level understanding of the embedded 
system of FIG. 29 may be obtained because it is a high-level functional block diagram of the 
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embedded system and because a virtual test bench may be used to interact with the virtual 
embedded system. Moreover, in a preferred embodiment a graphical hardware debugger 
permits the execution to be selected to trace the behavior of the embedded system. FIGS. 30- 
3 1 are screen shots of browsers and control windows useful for rapid navigation, traversal, and 
5 design of embedded system designs having multiple levels of hierarchy. 

[0101] The IDE preferably includes a test bench builder, software debugger, and 

waveform viewer to emulate other physical test apparatus commonly used to assess the 
operation of an embedded system. As shown in FIGS. 33A and 33B, a waveform viewer is 
also preferably included for viewing a selected signal as a function of time. As shown in the 

10 exemplary screen shot of FIG. 34A, in a preferred embodiment a test bench builder 3405 is 
included for forming a graphical representation of a test bench. As used in this application a 
test-bench builder is an application that allows a designer to build a simulation of an embedded 
system by adding graphical objects (e.g., buttons, LEDs, LCDs, alpha-numeric keyboards, 
telephone keypads, register viewers, memory viewers, resource meters, etc.) to mimic a 

15 physical human-machine interface of an embedded system product. As examples, a keyboard 
interface 3410 may permit a user to input commands via the keyboard while an LCD interface 
may mimic the outputs of a physical LCD. This graphical test builder may be used to inject 
stimuli into the simulation and observe the system behavior. FIG. 46 is a block diagram 
showing a test bench interacting with a simulation engine. FIG. 47 is a flow chart illustrating 

20 a preferred method for a debug interface to negotiate a communication interface between a test 
bench control and a variable of the simulation. 

[0102] Referring to FIG. 35, during a simulation of an embedded system, a simulation 

cockpit is preferably included that provides information on the status of a simulation and that 
loads and updates the test bench objects. Referring to FIG. 36A, a software debugger 3685 is 
25 also preferably included for loading and testing software that is executed on the virtual 

platform. The software debugger 3685 preferably includes means to establish break-points of 
execution of the software application and to view and modify processor and system resources 
such as the processor stack, registers, and memory. FIG. 36B shows an example of a software 
debugger interface window 3685 superimposed over a design window 3620 of a virtual 
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embedded system. As shown in FIG. 34C, in one embodiment a user may select breakpoints 
of execution 3900 in the hardware description associated with the execution of the simulation 
reaching a command flow of a particular graphical construct 3980. Referring to FIG. 36A, 
note that the software debugger 3685, virtual test bench 3605, and design window 3620 of the 
5 embedded system may be viewed simultaneously. This provides the benefit that each interface 
provides a display and control of a different aspect of the system, which is particularly 
beneficial in developing low-level software routine or when integrating hardware and software 
partitions. 

[0103] As illustrated in FIG. 37, in a preferred embodiment a CPU IO Configurator 

10 3702 application is included to permit a processor simulator to map addresses spaces to 
peripheral virtual hardware models such that a processor simulator 3705 communicates 
read/write memory transactions to the appropriate addresses of virtual hardware such as 
hardware elements 3720 and 3730, while the virtual hardware sends interrupt signals to the 
appropriate addresses of the processor simulator 3705. As previously described, in a 

15 preferred embodiment, processor simulator 3705 is an instruction set accurate simulator. It 
will be understood that the mapping of read/write memory transactions and interrupt signals 
permits the implementation of a high-level model of the embedded system that is sufficient to 
execute a software application on the virtual embedded system. FIG. 38 is an screen shot of an 
exemplary processor symbol 3805 and two peripherals 3830 and 3840. FIGS. 3<M0 are 

20 exemplary screen shots showing a Configuration Wizard and configuration data for coupling 
read/write memory transactions and interrupt signals between the FSM representation of the 
hardware peripherals and the ISA processor. Details of the CPU attributes, bus attributes, and 
other details may be included in the Configuration Wizard. Referring to FIG. 38, a 
configuration wizard permits a user to rapidly form a high level symbolic diagram of 

25 read/write and interrupt interactions that accurately maps signals between address spaces. 

[0104] The DDE of the present invention permits a model of an embedded system to be 

created in a comparatively short time, e.g., within a few hours to a few days for many typical 
embedded systems. The short model development time is due, in part, to the graphical user 
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interface, which in a preferred embodiment includes numerous features and a powerful FSM 
design language (MAGIC-C) for rapidly creating FSM models and forming re-usable models. 
However, another factor is that the level of abstraction is high enough to not require low-level 
hardware implementation details while still having sufficient software-centric details to 
execute a user application. This makes the IDE of the present invention consistent with 
developing a virtual prototype that is a useful functional representation of an embedded system 
within the comparatively small time allotted in typical projects for evaluating IP blocks and 
creating an architecture definition. The resulting virtual prototype can be used as a 
development target for embedded software early in the development cycle, e.g., before any 
physical hardware or prototype is available. Moreover, as described below in more detail, a 
user may load production quality code (e.g., binary code compiled for a specific processor) for 
execution on the virtual embedded system. The high level of abstraction facilitates sharing 
models of embedded systems with others. One aspect of this is that the level of abstraction is 
high enough that no hardware implementation details are disclosed, which makes it possible to 
provide embedded system models to others while still preserving proprietary trade secrets 
required to manufacture the final end-product. Additionally, the high level of abstraction 
makes it comparatively easy to understand the function and operation of the embedded system 
model, which facilitates sharing an embedded system model with others as an evaluation tool 
or for procurement of goods or services related to the embedded system design. 

[0105] As described below in more detail, the high level of abstraction permits the 

simulation to execute a software application at an acceptably high rate of execution for 
software debugging, e.g., permits useful software debugging in the first few weeks or months 
of a development phase. Consequently, a virtual prototype formed in accord with the present 
invention may be used as hardware emulator for debugging software. Software execution rates 
in excess of several MIPS may be achieved with the simulation running on computer with 
speeds of 450 MHz and above. Thus, the virtual prototype is available early in the 
development phase (e.g., at the architecture definition stage) to function as a hardware 
emulator for developing and debugging software. By way of comparison, a conventional 
hardware emulator, such as a FPGA hardware emulator, typically arrives late in the 
development phase after hardware implementation details are developed (and is sometimes not 
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used at all because of the high cost of a FPGA hardware emulator). Consequently, a virtual 
prototype in accordance with the present invention makes possible the concurrent development 
of both the hardware and software partition in the development phase. A large reduction in 
development time and/or improvements in quality are facilitated because a virtual prototype 
5 may be used for early software development, concurrent hardware and software development, 
and early hardware/software integration. An alternate way of describing these benefits of the 
present invention is that the creation of a virtual prototype that is a functional specification of 
an embedded system facilitates true co-design, since hardware designers can use the functional 
specification to develop hardware implementation details while software designers can use the 
10 functional specification to perform early evaluation, early development and debugging of 
software applications, and consequently early hardware/software integration. 

[0106] It will be understood that the DDE of the present invention may be coupled to a 

network server, such as a web server. FIGS. 41-44 illustrate a preferred implementation of the 
IDE of the present invention as a web-based service. As shown in FIG. 41, a persistent 
1 5 communication channel may be established between a client computer and a network server. 
FIG. 42 shows another implementation of a client-server architecture having increased security 
for web-based service. FIG. 43 is an exemplary screen snapshot of the IDE design window on 
the browser of a client computer. FIG. 44 is a block diagram illustrating a preferred web-based 
service including a collaborative design manager. 

20 [0107] In one embodiment, the IDE is used to form virtual platforms for evaluating IP 

components. In a preferred embodiment, a web-based service is used to market embedded 
systems components or sub-systems (e.g., a processor core) by hosting virtual platforms on a 
central server. In one embodiment, a user can use a client computer to access the virtual 
platform and evaluate the virtual platform executing benchmark software selected by the user, 

25 e.g., by executing the simulation and observing the operation of the embedded system using the 
virtual test bench, debugger, and other tools. In one embodiment, the virtual platform is 
designed to emulate the function of a reference evaluation board used to evaluate a processor 
core or other IP component during an evaluation phase of an embedded system project. 
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[0108] Referring to FIG. 48, in one embodiment an interactive walkthrough content 

may be associated with a virtual platform to provide content for explaining the operation of a 
virtual platform. In one embodiment, additional marketing data is recorded and associated 
with a user's on-line usage an interaction with a virtual platform. 

5 [0109] An on-line IP evaluation service provided benefits to both embedded system 

designers and vendors. From the perspective of embedded system designers, virtual evaluation 
saves time compared to conventional evaluation using physical reference boards because 
virtual evaluation is available on-line (eliminating ordering and shipment delays), because 
virtual test benches and other evaluation tools facilitate rapid evaluation, and because an on- 

1 0 line IP evaluation service permits IP from multiple vendors to be conveniently evaluated. 
From the perspective of IP vendors, virtual evaluation saves money and reduces the need for 
customer support. In particular, there is a low incremental cost to providing a virtual 
evaluation platform. Additionally, by monitoring the on-line usage and interaction with virtual 
platforms, IP vendors can obtain valuable marketing data on processor core types and hardware 

1 5 peripherals desired by embedded system designers during an evaluation phase. 

[0110] Referring to FIG. 8, the IDE of the present invention may be used to form a 

simulation of an embedded system that may be used as a functional specification of the 
embedded system for the procurement of a good or service related to the embedded system. In 
a preferred embodiment, a virtual embedded system is created by a user, hosted on a web- 

20 based service, and used as an executable functional specification (i.e., as an interactive 

simulation that can be used to understand the function of the embedded system) for procuring a 
good or service related to the embedded system. In one embodiment, the executable functional 
specification may be downloaded. In one embodiment, a detailed design may be provided by 
the executable functional specification. In another embodiment, the level of hierarchy (e.g., the 

25 views of hardware, signals and pin symbols shown) are set at a part-level appropriate for a 
vendor. Additional information or annotation may also be included at the part-level. Test 
benches may also be configured to demonstrate the function at a part-level. In one 
embodiment, a virtual platform serves as a functional specification for procuring goods or 
services early in the development cycle before a working prototype is fabricated. In one 
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embodiment, described below in more detail, the virtual platform is used as a basis of a request 
for quote. 

[0111] A web-based service may also be used to facilitate the development of an 

embedded system project having one or more project members working in different 
5 geographical locations. Ia one embodiment, members of a user group have access privileges to 
a virtual platform hosted by the web-based service. Members of the user group may be granted 
privileges to run, copy, modify, annotate, or edit a version of the virtual platform. In one 
embodiment, a virtual embedded system (virtual platform) is created by a user group early in a 
development phase, e.g., shortly after the embedded system architecture is defined. Hardware 

10 engineers can then use the virtual platform as a basis for defining the hardware implementation 
while the software engineers can use the virtual platform to develop the software. Moreover, 
modification and design updates may be shared using a virtual prototype. In one embodiment, 
version control is included to permit members of a design team to create, edit, or modify a 
version of a virtual prototype. For example, a version of the virtual platform may be created to 

1 5 include a design update and then electronically communicated to other members of the design 
team (e.g., via a web-based service). 

[0112] In one embodiment, the IDE of the present invention is used to provide a 

common, compatible design environment that facilitates the aggregation of IP components 
from different sources into a common service, preferably a web-based service. In particular, a 

20 preferred embodiment may include libraries containing virtual platforms and models of IP 
components from multiple vendors that are compatible with the IDE. This allows a user to 
select IP components of interest that they may add or, in the case of hardware models, modify 
for their own design. Additionally, libraries of reference hardware peripherals and sub-systems 
may also be included. Additionally, other libraries, such as a library of virtual test benches 

25 may be included. The aggregation of IP in a single design environment improves the 

efficiency of the design process by allowing embedded system designers to efficiently design a 
functional hardware description of an embedded system by picking and choosing IP 
components that are all compatible with the DDE. Moreover, the interaction of two or more IP 
components of a virtual prototype of embedded system may be rapidly evaluated in the IDE, 
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which is typically not possible using conventional physical reference evaluation boards which 
are developed and manufactured for a single IP vendor. 

[0113] Further details of various aspects of preferred embodiments of the present 

invention are described below in more detail in the following sections. 

5 I. Preferred Finite State Machine Representation Of Hardware Components And Processes 

[0114] The hardware partition of an embedded system typically includes at least one 

electronic hardware component (also known as a hardware "element"), such as a peripheral 
hardware component, forming a portion of the embedded system. Several hardware 
components may be included in the hardware partition. In accord with the present invention, 

10 the electronic components of the hardware partition are preferably modeled as concurrent, 
communicating Finite State Machines (FSMs). Referring to FIG. 17A, a conventional 
approach to designing a finite state machine description of hardware includes forming a state 
diagram and creating a state table of the state transitions. This model describes a system as a 
set of interacting machines, each having a local state. At an initialization time ( t=0), all FSMs 

1 5 start executing from their Start construct, being the explicit entry for an individual FSM. The 
behavior between the Start construct and the first State construct represents the initialization 
behavior of the FSM. At t=0, this behavior is executed for each FSM, until all FSMs reach their 
first State. The actual execution and progress of time start from that point on. In a preferred 
embodiment, the FSM models have process-level concurrency, inter-task communication, 

20 hierarchy, at arbitrary levels of nesting, and real-time support, by means of clocks and timers. 

[0115] A preferred embodiment of the present invention includes a design language to 

rapidly create finite state representations of hardware components and processes in a visually 
intuitive format and which have a sufficiently low simulation overhead to permit a high-speed 
execution of software. In a preferred embodiment, the design language is an object-oriented 
25 design language with graphical attributes that facilitate quickly assembling a FSM model of 
system from pre-existing component models. 

[0116] One aspect of the present invention is a design language, preferably an object- 

oriented design language, to form FSM models of hardware components and processes. FIGS. 
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19A and 1 9B are a table of preferred graphical objects (described by the inventors as 
"graphical constructs") for forming FSM models of hardware components and processes. As 
described below in more detail, the behavior of each object includes a graphical component 
associated with the shape of the object and a textual component input by a user. The graphical 
5 objects shown in FIG. 1 9 have shapes that are a subset of the graphical shapes of the 

Specification and Description Language (SDL), such as the SDL-92 language, and preferably 
combined with the ANSI C/C++ language to permit a user to define the behavior of a task 
construct. The Specification and Description Language (SDL) is a tool described by the 
international telecommunications union (ITU) for the specification and description of 

1 0 communication protocols in telecommunications systems. Conventional SDL provides a 
Graphic Representation (SDL/GR) and a textual Phrase Representation (SDL/PR), which are 
equivalent representations of the same semantics. In SDL a system is specified as a set of 
interconnected abstract machines that are extensions of the Finite State Machine (FSM). SDL 
permits a FSM model to be described as a directed graph of connected graphical objects 

15 (known as "symbols") expressing an extended finite state machine. The behavior of an SDL 
object is governed by its shape (which defines aspects of the function of the object) and textual 
semantics associated with the object (e.g., typically input inside of the graphical object). SDL 
includes a start object, state object, input object, state objects, text objects, and output objects. 
Details of SDL-92 are described in the book "Systems Engineering Using SDL-92," by Anders 

20 Olsen, Birger Moller-Pedeson, Rick Reed, and J.R.W. Smifli, (Elsevier 1 994), the contents of 
which are hereby incorporated by reference. 

[0117] Conventional SDL, which was developed to describe communication protocols 

in telecommunications systems, has several drawbacks that limits its usefulness for designing 
hardware elements and processes for embedded systems. First, conventional SDL lacks 
25 language concepts for describing electronic hardware. Second conventional SDL includes 
semantics for described the behavior of complex communication systems that do not apply to 
the hardware design of conventional embedded systems. These complicated semantics 
increase the learning curve for conventional SDL. Third, conventional SDL has a high 
simulation overhead. The simulation overhead is about a factor of 1 00-to-l 000 times larger 
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than desired. The large simulation overhead of conventional SDL, results, in turn, in a 
corresponding reduction in the execution speed of a FSM simulation. 

[0118] A preferred embodiment of the present invention includes a design language 

developed by the assignee of the present invention and known by the trade-name of "MAGIC- 
5 C". One aspect of MAGIC-C is the elimination of features of SDL required for 

telecommunications applications that are unnecessary for modeling hardware in order to reduce 
the simulation overhead. In accord with one embodiment of the present invention, the 
elimination of unnecessary aspects of SDL results in an object file of a hardware description 
having a low simulation overhead, e.g., a simulation overhead that is estimated by the inventors 
10 of the present application to be about a factor of 100-to- 1 000 lower than conventional SDL. 

[0119] Many aspects of conventional SDL can be eliminated or modified to adapt SDL 

for describing the hardware of an embedded system. For example, conventional SDL 
processes include Inheritance and specialization of data types, state transitions and procedures 
(by means of virtual types, transitions and procedures). These constructs, require a substantial 

1 5 simulation overhead, because they require dynamic lookup and checking. However, these are 
not very useful for a hardware simulation and may be eliminated. Similarly, conventional 
SDL includes polymorphism that is not very useful for modeling physical hardware and which 
thus may be eliminated to reduce simulation overhead. Conventional SDL also includes value 
returning (remote) procedures useful for software description but which impose a substantial 

20 simulation overhead because of the required stack parameter passing. Since these value 

returning features are not required for hardware modeling, they may be beneficially eliminated. 
Conventional SDL includes exported variables, called remote variables, which are not 
applicable to hardware modeling having encapsulated modules that communicate through 
signals and signal pins and thus this aspect of SDL may be beneficially eliminated. 

25 Conventional SDL includes features for dynamic process creation that requires extensive 
process tracking during simulation (e.g. in complex process tables), slowing down a 
simulation. However, for the case of hardware modeling, all the processes are known at 
compile-time such that dynamic process creation is not required. Conventional SDL, which 
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was designed for telecommunication applications, also has a large simulation overhead because 
it uses virtual communication channels convey multiple signals that require dynamic routing to 
be performed during the simulation. However, virtual communication channels are not 
required for modeling hardware. Conventional SDL includes process identifiers (Pid) that are 
5 useful for referring to software processes (e.g. when executing on an operating-system), but 
which are unnecessary for hardware modeling. SDL includes provisions for spontaneous 
transition to model unreliable parts of a telecommunications system but which are unnecessary 
for a hardware simulation- Conventional SDL includes a prioritized signal-in construct require 
queue manipulation during simulation. However, this feature of SDL is unnecessary for a 

1 0 hardware simulation using a FIFO based queueing. Conventional SDL includes continuous 
signals and enabling conditions, which incur a very high simulation overhead because these 
signals need to be continuously updated and monitored for a triggering condition. These can 
be eliminated for a hardware simulation of an embedded system. Conventional SDL also 
includes services. A service differs from a process in that it does not execute concurrently with 

1 5 other services in the same process, but rather is implemented as part of the process' behavior. 
These can be eliminated for a hardware simulation. Conventional SDL includes features for 
creating parameterized types. In conventional SDL, signals, processes and services can be 
parameterized, making their actual type only known at run-time. This induces tremendous 
simulation overhead as it requires checking of the value and range of the parameters at run- 

20 time. In hardware modeling, all the types are known at compile-time making a parameterized 
type feature unnecessary. SDL also includes user-defined operators, which are not needed for 
hardware modeling. 

[0120] In a prefeired embodiment of a design language having graphical symbols 

adapted from SDL, the ANSI C language is used to specify the behavior of a task construct. In 
25 a preferred embodiment of the present invention, a task construct is restricted to a formal 
specification in ANSI C. ANSI C is widely used by embedded system designers and has a 
minimal learning curve for users, which is important for quickly composing new 
systems/models. Additionally, ANSI C has high-quality optimizing compilers/tools, which 
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make the use of ANSI C to define task behavior compatible with a high-speed system 
simulation. 

[0121] In a preferred embodiment of the present invention, the design language 

includes constructs for Symbols and symbol pins. The modeling of hardware modules is 
5 facilitated by the ability to create symbolic representation of hardware module that has 
representation of physical pins. One benefit of a Symbol is that Symbols can have multiple 
instances, supporting re-use of models and stimulating the quick development of emulators. 
These constructs are useful for encapsulating aspects of behavior so they can be re-used easily 
as library elements, stimulating the rapid composition of new hardware emulators. Also, it 
1 0 allows for intuitive modeling of connected hardware components in a hardware architecture, 
facilitating the rapidly composition of new emulators. Pins are used to connect symbol 
components with each other, or with the instruction-set simulator, to pass the memory 
transactions to the peripheral models. 

[0122] In a preferred embodiment described below in more detail, a static compile-time 

1 5 parameter scheme is used for blocks, processes and symbols. A static compile time parameter 
reduces the simulation overhead, since parameters do not need to be calculated during the 
simulation. 

[0123] FIG. 17B shows an example of a finite state machine using a sequence of 

graphical object (hereinafter "constructs") that has a graphical symbol portion and a textual 

20 portion. A plurality of graphical constructs is preferably included with the shape of the object 
defining a behavioral attribute or function of the object. The textual portion of the graphical 
construct also defines the attribute or function of the object. As shown in FIG. 17B, a 
graphical object may be linked to other graphical objects as a sequence of execution (e.g., a 
command flow of execution from top to bottom in analogy to a conventional flow chart). As 

25 shown in FIG. 1 8, in a preferred embodiment hardware elements or processes may be 

represented as communicating finite state machines using a broadcast signal communication 
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model. FIG. 20 shows an example of a hardware counter implemented as a sequence of 
graphical objects. 

[0124] As shown in the screen shots of FIGS 21-24, toolbars having icons representing 

the symbols of the graphical constructs and steps in the creation of the finite state machine 
5 representation are preferably included to facilitate the rapid creation or modification of finite 
state models. This permits a menu-driven method of forming FSM representation in which a 
graphical construct is selected from a window; text, variables, or code are associated with the 
graphical object, and the graphical object is then connected (linked) to other graphical objects. 
Referring back to FIG. 10, a graphical database and a behavioral database is configured to 
10 convert the graphical object representation of the FSM into an equivalent semantic from which 
code can be generated to represent the hardware specification. 

[0125] FIGS . 1 9 A and 1 9B comprise a table showing a list of preferred graphical 

constructs for forming FSMs. A preferred graphical symbol and function of each construct is 
shown. A Declaration construct 1902 is a construct used to define local variables and signals. 

15 A Start construct 1 904 defines a starting point of the finite state machine execution at the 

initialization time. A Task construct 1906 is an execution block containing at least one ANSI- 
C statement to be executed. A State construct 1908 defines a location where the finite state 
machine waits until a triggering signal is received. A Decision construct 1910 directs a flow of 
execution based on the result of the expression evaluation inside the decision construct. A 

20 Signal-Out construct 1912 is used for sending of a communication signal. A Signal-In 

construct 1914 is used for receiving a communication signal. A Connector construct 1916 is 
used to connect the control between designs spanning over multiple pages. A Symbol 
construct 1920 is used to capture design hierarchy and structure. Pins are includes on the 
outline of the symbol construct 1920 for communication of signals. A Block construct 1922 

25 captures design hierarchy and structure. A Block communicates through signals expressed by 
signal name. A Block can contain multiple processes. A Process construct 1924 acts as a leaf 
node in the design hierarchy describing a single finite state machine. 
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[0126] In a preferred implementation of the present invention, objects can be grouped 

into larger units. As shown in FIG. 28 this permits a top-level block diagram to be created 
which can be nested at different levels of hierarchy to show the functional aspects of the block 
at the desired level of detail. Referring to FIG. 29, this permits high-level diagrams of the 
5 embedded system to be formed with a sufficient level of detail and textual description to 

provide an intuitive understanding of the function of the system at a desired level of hierarchy. 
This introduction of hierarchy allows powerful abstraction and hiding of low-level details. In a 
preferred embodiment, hierarchy is created by defining Blocks, Processes, and Symbol 
constructs. A Block construct is a container for FSM Finite State Machines, and may be part 

10 of a larger block or process. Each Block may in turn consist of a Process or a substructure of 
Blocks. There is no specific behavior associated with a Block construct. Its behavior is the 
combined behavior of its underlying finite state machines. A Block construct may contain a 
Declaration construct, which in turn contain signal and variable definitions. Figure 1 6 shows a 
Block construct containing a single Process construct, two Block constructs and a Declaration 

15 construct. 



[0127] Hardware registers are declared as simulation variables in declaration blocks in 

a Magic-C design. Variables that need to be made visible in the test bench are are preferably 
implemented as C++ classes that implement specific Component Object Model (COM) 
interfaces that allow them to connect to test bench controls. They use operator overloading so 
20 they can be used in code as simple types. The operator overloading allows them to update the 
GUI each time their value changes. This allows them to be used in a very simple manner (like 
a primitive type), while giving complex functionality (updating the GUI). 



[0128] The behavior of a Process is described as a FSM. When started, a Process 

executes its start transition and enters the first state. The reception of a signal triggers the 
25 transition from one state to the next state. In transitions, a Process may execute Actions. 

Actions can assign values to variables, perform calculations, branch on values of expressions, 
call functions and procedures, and send signals to other Processes. A Process can define local 
variables, defined by the scope of the Process, by means of a Declaration. Initialization places 
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all the Process FSMs into the Start Construct, as depicted by an oval. At that point, the Process 
executes the action of its start transition, as described in the Task Construct (depicted by the 
rectangle). In a preferred embodiment, a designer specifies the Task Construct behavior using 
plain (ANSI) C++, minimizing the learning curve typically associated with a new language or 
5 paradigm. Each Process receives (and keeps) signals in an (implicit) queue. In a State, depicted 
by a rectangle with rounded sides, the Process takes the first signal from the queue. In the 
example, the interrupt controller waits for an interrupt signal, as sent by one of the two 
peripheral devices. The Symbol for a Signal-In construct is a rectangle with an arrow pointing 
inward as either its left or right side. 

1 0 [0129] The FSMs communicate with each other (and with the environment) by sending 

and receiving signals to each other. From each state, a state transition to another state can be 
made only upon receiving a signal generated by the environment or by another concurrent 
FSM. When making a state transition, the signal sending constructs (Signal-Out) and the 
Task/Block constructs on the state transition, are executed, and the FSM reaches a new state. 

1 5 [0130] For communication, signals use a broadcast mechanism. In other words, signals 

are visible and accessible to all the Process FSMs, which have the signal defined in their scope. 
Figure 18 has the implicit signal communication queues explicitly drawn for each Process 
FSM. All the broadcasted signals are received in these queues, to be popped by the FSM inside 
the Process. 

20 [0131] Communication through signals can happen in two ways. First, for named 

signals, no physical connection needs to be made, by using the same signal name in both 
receiving constructs and sending constructs at different places in the design hierarchy, 
communication is established. Second, symbol interconnections may be used coupling pins on 
the perimeter of symbols to represent a communication link. 

25 [0132] Clocks and timer operators are preferably included that are definable by the user 

to define clock/timing signals of interest. Time progresses by waiting for the clocks and 
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timers. In addition, broadcasted signals are received instantly by all Processes contained in the 
scope of the Block construct where the signal is defined. As such, communication is always 
completed in zero time. 

[0133] Referring back to FIG. 1 1 , in one embodiment the simulation engine has two 

5 queues of signals: the Event Queue and the Time Queue. Every time a signal is sent that has 
the Signal-Out Construct, signal is put in the Event Queue. When a Timer or Clock signal is 
scheduled to happen in the future (by using a command set(now+X, t)), the signal is put in the 
Time Queue, along with the time it should be triggered and scheduled. The simulation engine 
dispatches signals from the Event Queue until the Event Queue is empty. When that happens, 
10 the simulation engine pops the next signal from the Time Queue, sets the simulation time 
(now) to the time specified in the signal, and dispatches the signal. In one embodiment, two 
rules apply to simulations. First, if the event queue never empties, simulation time never 
advances. Second, time does not advance when using set(now+X ,t), but when t is actually 
dispatched (with the signal being a Timer or Clock signal). 

1 5 [0134] In a preferred implementation, Symbol Constructs can be created to represent a 

Block, a Process or a CPU, which can be selected by the user upon creation of a symbol. 
Symbols Constructs allow users to encapsulate behavior, and make it ready for re-use, as 
symbols can be instantiated over and over again. The communication of signals crossing the 
symbol perimeter is explicitly indicated by symbol pins on the perimeter of a symbol; this in 

20 contrast to Blocks and Processes where there are no pins, as the signal connection (with signal 
defined in higher scopes) is done by name, rather than by wire connection. An external pin 
interface is preferably made by means of a external signal declaration, as for example 
'extern_signal inl(int);', and the Signal-In and Signal-Out constructs. 

[0135] In a preferred embodiment, a Symbol Creation Wizard is included to facilitate 

25 the creation of Symbols. A symbol creation wizard is preferably configured to permit a user to 
create new symbols from scratch: in this case, the user specifies the name of the symbol, its 
implementation, and the tool will automatically create the symbol framework for an empty 



39 



WO 01/95161 



PCT/US01/17873 



template. The Symbol Wizard preferably permits a user to wrap existing Blocks or Processes 
into a new symbol. For example, the symbol creation wizard preferably permit a user to point 
to an existing Block or Process followed by the tool creating the symbol framework linking the 
Block or Process pointed to as the implementation of the Symbol. 

5 [0136] Secondly, the Wizard facilitates the creation of new symbol pins by offering a 

dialog window, where the user types in the name of the symbol and selects its location, and the 
Wizard takes care of the rest. 

[0137] In a preferred embodiment, Blocks, Process and Symbols may be parameterized 

with different initial conditions. Parameters are special variables inside a Block, Process, or 

1 0 Symbol whose values can be modified on a per-instance basis without the need to re-compile. 
Parameters can also take on the value of other parameters. This allows the use of parameters 
that modify the value of several other parameters. Parameters can be seen as per-instance 
adjustment knobs. A parameter preferably has a parameter declaration. After declaring a 
parameter inside a Symbol, the parameter can optionally be annotated on the outline of a 

15 symbol and its instances. For example: To declare an integer parameter with default value 5 in 
the ANSI C language, the following parameter syntax could be used: VS_PARAM int 
Delay(5). 

[0138] Design components can be packaged into symbols, to be stored in IP libraries. 

These IP blocks can be bundled and shipped together with their corresponding test benches, 
20 facilitating the testing of the IP, when integrating and re-using it. In one embodiment, the 
creator of a symbol is provided with parameters to control the ability of a user to edit the 
symbol. For example, in one embodiment the creator of a Symbol could select that the Symbol 
is non-editable and/or that the finite state machine or Process within the Block is non-viewable. 

[0139] The above-described features provide the benefit that an engineer can rapidly 

25 design a finite state machine representation of hardware components and processes that has a 
comparatively low simulation overhead. Although this time required to create a FSM 
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representation will depend upon the complexity of the hardware and the experience of the 
engineer, the present invention permits many conventional hardware components and 
processes to be typically modeled in time periods of a few hours or a few days, depending 
upon the complexity of the finite state machine. Moreover, since the FSM representation does 
5 not require low-level hardware implementation details, a FSM model of the hardware partition 
can be created extremely early in the design cycle, e.g., a few days or weeks after a processor 
has been selected and a high-level architecture definition of the system has been developed. 
Additionally, since the present invention permits FSM models to be rapidly created or 
modified, the FSM models may be used as an aid to define the system architecture. As one 
1 0 example of a way in which the present invention may be used to define a system architecture, 
several different versions of a virtual prototype may be created and evaluated to select a system 
architecture from the virtual prototype having the best characteristics. As another example of 
using a virtual prototype to define a system architecture, a virtual prototype may be modified 
until desired characteristics are achieved. 

15 n. Preferred Processor Model 

[0140] In order to debug software on a virtual platform, a high-speed processor 

simulator is desired. As previously described, in a preferred embodiment a processor core is 
modeled as an instruction set accurate simulator. An instruction set accurate simulator 
simulates the functions of a processor core that are visible to embedded system software, which 
20 permits binary code compiled for a target processor to be loading using a software debugger 
and executed using the instruction set accurate simulator. An instruction set accurate simulator 
is typically at least ten to twenty times faster than cycle accurate processor models that include 
details of the processor pipeline and many orders of magnitude faster than processor models 
including gate level implementation details. 

25 [0141] The instruction set accurate simulator of a processor core is preferably 

optimized for speed of execution in a system simulation. In one embodiment, the models are 
hand-written C/C++ models for a particular processor core, with assembly routines for the 
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critical portions to improve speed of performance. Conventional optimization techniques may 
be used to optimize the performance of the simulation engine. In particular, a performance 
analyzer program may be used to optimize the performance of compiled code, e.g., using an 
iterative technique. La some cases, the simulation engine may not need to call the signal 
5 processing function of every FSM, i.e., the simulation engine may be performing unnecessary 
work. In one embodiment fee simulation engine is coupled to the code generator and checks if 
a FSM is receiving a signal that is sensible to the FSM before calling the signal processing 
function of die FSM. If the receiving FSM is not sensible to the signal, then the function is not 
called. 

1 0 [0142] Referring to FIG. 37, in one embodiment, a CPIHO Configurator application is 

used to facilitate an address mapping of virtual signals between the processor and the hardware 
peripherals. The CPU-IO Configurator's task is to serve as an interface between peripheral 
models and an arbitrary processor simulator. These associations ensure that the appropriate 
signal will be dispatched to the peripheral model when a particular address is read or written. 

1 5 This approach has a high level of abstraction that provides a desirable execution speed while 
providing sufficient detail to understand die behavior of the software partition interacting with 
the hardware partition. 

[0143] In one embodiment, adding a processor simulator into a simulation is as simple 

as dragging the processor symbol from a library into the design window. An I/O Configurator 
20 Wizard (see FIGS. 39-40) will lead a user through the configuration of the processor and the 
attachment of the different peripherals, effectively shielding a user from all the underlying 
hardware and co-simulation interface details. In a preferred embodiment, an IO bus object is 
used to define data bus attributes. 

[0144] Figure 37 illustrates the communication between an arbitrary processor 

25 simulator and the virtual hardware. The solid arrows in the figure represent the transmission of 
signals between the processor model and the hardware simulation. The dashed arrows indicate 
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the transfer of data through a well-defined application procedural interface. The meanings of 
these arrows are defined below. 

[0145] A read signal is sent from the processor simulator to the hardware partition 

whenever the processor requires data from a peripheral. It contains the address where the read 
5 should take place. This address is used by the CPU-IO Configurator to determine the target 
peripheral for the read. Data will be returned to the processor through the data as described 
below. 

[0146] A data method call is part of the IOBus object inside the CPU 10 Configurator. 

It is used to send data from peripheral model to the processor simulator in response to a 
10 previous read signal. Typically, the peripheral model will return data to the CPU -10 
Configurator in the form of a signal. 

[0147] A write signal is transmitted from the processor simulator to the hardware 

peripheral whenever the CPU needs to write data to a particular peripheral model. The signal 
payload contains the target address in addition to the data to be written. The address is used by 
15 the CPU-IO Configurator to determine the target peripheral for the write. 

[0148] A writeDone method call is an optional method call that may be used if the 

peripheral model wishes to acknowledge memory writes from the CPU. A signal 
acknowledging the write is first sent from the peripheral model to the CPU-IO Configurator. 
Logic in the CPU-IO Configurator then uses this method (part of the IOBus object) to notify 
20 the processor simulator that the write has been completed. This procedure is useful in 

synchronizing the peripheral model with the processor simulator, and is typically used to 
simulate variable memory write operation timing. 

[0149] An interrupt signal is used to alert the CPU that an interrupt has occurred. It 

does not contain a payload or any other state information as it is expected that the CPU will 
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manipulate the peripheral model of the interrupt controller to correctly service the interrupt. 
The name of this signal will vary according to the processor model being used. 

[0150] An interrupt_ack signal is sent back to the CPU after an interrupt as a 

notification that the interrupt for this source may be cleared. The name of this signal will vary 
5 according the processor model being used. 

[0151] An auxiliary side-band signal is processor-specific and includes general purpose 

I/O pins, external registers, co-processor interface, etc. 

[0152] Whenever a user creates a new virtual prototype, a new instance of IO 

Configurator is preferably created to coordinate the read/write and interrupt transactions. 

10 Referring to Figure 38, Figure 38 shows an IO Configurator block that is attached to two 

peripheral blocks. For each peripheral to be connected to the CPU-IO Configurator, an address 
range (i.e. start and end address) as well as a pair of signals (one for read, one for write) needs 
to be created inside the IO Configurator. This will map memory transactions within that range 
to the specified signals, and the pins with the same names as the signal pair. To perform this 

1 5 action, a double-click on the IO Configurator symbol, is preferably performed and the 

Configurator Wizard appears as depicted in Figure 39. This Wizard simplifies the setup of 
CPUs considerably, and allows easy configuring of bus speed, type of processor busses, 
interrupt interaction, fixed- versus non-fixed memory timing, and signal naming. Pins are 
preferably coupled to the CPU-IO Configurator symbol for each signal which will be 

20 dispatched to a peripheral. Pins may also be added to a peripheral for data returned to the CPU 
(as described above for the data signal ) and for any write acknowledgements (as described 
above for the write signal). 

HI. Preferred Integrated Design Environment GUI For Designing Virtual Prototypes 

[0153] As previously described, in a preferred implementation of the present invention 

25 a menu-driven graphical user interface having point-and-click and drag-and-drop features is 
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provided to facilitate the rapid creation or modification of virtual prototypes. It will be 
understood that the benefits of the preferred menu-driven graphical user interface include 
reductions in the time required to create, edit, and modify a virtual prototype and IP 
components. The preferred GUI of the present invention permits a designer to design a high- 
5 level model of a virtual prototype in a short period of time, e.g., in as little as a few hours in 
some cases. 

[0154] FIGS. 12-14 show some of the aspects of a preferred sequence of interactions 

for designing a virtual prototype. Referring to FIG. 12, in one embodiment, this includes the 
following sequence of tasks: 1) Providing the user the option to Start A New Project 1204, 2) 

10 or to Open an Existing Project 1202; 3) Create (or Modify) System Design Specification 1210; 
4) Create (or Modify) Testbench(es) 1220; 5) Code Generation 1230; 6) Simulation and 
Debugging 1240, and add Save and Close Project 1245. Steps 1210-1240 may be repeatedly 
executed until a design in the current project meets the requirements, and when all bugs and 
errors have been removed Note that the creation of test benches can also be performed after 

1 5 step 1 230. In one embodiment, upon opening the design application, a user is presented with 
the option to start a new design project, or to open an existing project. When the former is 
chosen, the user specifies the name of the design project, the system sets up the full fill 
structure and database components. When an existing design is opened, the user can choose to 
modify the design, or to go straight to the code generation stage. Creation of a new design (or 

20 modification of an existing design) involves: (1) the creation of a new Block, Process or 
Symbol 1310, or (2) the use of existing blocks 1330 which can be taken from an arbitrary 
number of design libraries. The first step consists of creating the Block, Process, or Symbol 
outline 1315, followed by the specification of its implementation 1320. For the use of existing 
elements, the user attaches the libraries to his project 1335 , browses the libraries, and 

25 instantiates 1 340 the Symbol, Blocks, or Processes from the Library he wants to re -use. After 
placing the Symbols, the user needs to add the connections between the symbols to allow them 
to exchange signals. Alternatively, they can connect symbols using 'signal-connection- 
by-name', the same mechanism Blocks or Processes use to exchange signals. 
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[0155] New test benches can be created or existing test benches can be modified. The 

former consists of first opening 1360 a new test bench in the test bench editor, and then adding 
1362 and configuring 1364 one or more test bench controls consecutively. In a preferred 
embodiment, a test bench control is a single ActiveX entity, which can be used to interact or to 
5 display a specific aspect of a design, like injecting signals or viewing variable values. 

[0156] Code generation 1230 consists of selection the global and local project 

compilation, linking and output settings, followed by the actual C++ code generation for the 
simulation specification, and the compilation and linking using an external standard C++ 
compiler. 

[0157] Referring to FIG. 14, the simulation and debugging 1240 includes the following 

steps: attaching and removing of test benches to the design 1405, depending on which viewing 
aspect a user is interested in, starting of the simulation 1410, with optionally connecting to a 
processor model (i.e., an instruction set simulator) if a CPU symbol was instantiated in the 
design; setting and/ or. removing of breakpoints 1415 in the debugger IDE window. The user 
then has the option to run the simulation 1430, to run it for a specific number of cycles 1445, or 
to single-step 1446 the design. However, at all times, the user can abort the simulation 1285, 
which effectively ends the simulation. To the same extent, when the simulation is running, the 
user can break the simulation 1435, after which he later can continue from that point on. In a 
preferred embodiment, during the simulation the user the user can optionally view the signaling 
results of the simulation in the Waveform viewer 1490. 

[0158] A Design Window preferably permits the display of several views of the design 

including Blocks, Processes, Symbols, the symbol editor, and the Test Bench Builder. Figure 
21 shows a preferred design window format having toolbars with menu buttons to facilitate the 
design process. As shown in FIG. 22, a toolbar is preferably included to supports general 
25 functions such as opening files, cut and paste, zooming, and printing. FIG. 23 shows a 
preferred navigation tool bar with the menu-buttons labeled. As shown in FIG. 23, a 
navigation toolbar is preferably included to assist a user to quickly traverse the design 
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hierarchy and switch between different pages in a multi-page design. Additionally, menu 
buttons are included to generate new symbols (a Symbol Wizard button), to open a symbol 
shape, and to open a symbol implementation. As shown in FIG. 24, a MAGIC-C Graphical 
Construct Toolbar is preferably included that allows a user to add MAGIC-C graphical 
5 constructs (e.g., finite state machine representations) to the Design Window. As indicated by 
the icons on each button, a button for each commonly used graphical construct is preferably 
included to generate the graphical symbol of the construct in the design window. As shown in 
FIG. 25, a Compiler/Debugger Toolbar is preferably included to generate C++ code, and to 
control the running and debugging of a simulation. Examples of menu buttons for the 

1 0 Compile/Debugger Toolbar include a code generation button, a run button, a single-step 
debugging button, a run for n cycles button, a stop button, and a pause button. As shown in 
FIG. 26, a Test Bench Builder Toolbar is preferably included to represent the test bench 
controls, such as a LED, LCD, memory viewer, ASCII terminal window, resource meter, or 
signal button, and the test bench builder, allows a user to quickly add these controls to a test 

1 5 bench. A Symbol Editor Toolbar (not shown) is also preferably includes to facilitate the 
symbol manipulation functions, to edit and create new symbols using a Symbol Wizard to 
reduce the symbol creation to a couple of mouse clicks. As shown in FIG. 27, a status bar is 
preferably included. 

[0159] Referring to FIG. 30 a Design Browser 3000 is preferably included which 

20 comprises a hierarchy browser 3010, signal browser 3020, and signal connectivity browser 
3030, allowing in a single click to quickly browse and navigate a design's hierarchy or signal 
connectivity. The Design Editor preferably supports multiple design browsers allowing the 
designer to quickly and easily traverse the design depending on interest. 

[0160] The Hierarchy Browser 30 1 0 shows the hierarchy of a design. For each instance 

25 of a document in the design (Process, Block, and symbol) there is an entry in the Design 

Browser. The Design Browser only shows the instance name of documents. Double-clicking 
on a specific instance in the Design Browser takes the user to the implementation of the 
instance. 
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[0161] The Signal Browser 3020 displays the signals that are present at each of the 

different scopes in the design. It also shows how those signals are being used (Signal-In, 
Signal-Out, Signal Save, Set Clock, Set Timer). Double-clicking an entity in the Signal 
Browser opens a Design window with the corresponding signal use. The Signal Browser shows 
5 the hierarchy of a design, since each level has its own scope. For each instance of a document 
in fee design (Process, Block and Symbol), there is a "scope" entry in the Signal Browser. An 
example is given in FIG. 30. FIG. 45 shows a table describing the meaning of each of the icons 
in the Signal Browser: 

[0162] The Signal Connectivity Browser 3020 shows the path of one signal in the 

1 0 design, indicating what fee Processes are doing with fee signal. It is called the Connectivity 

Browser because it shows the relationship between the sender of a signal and its recipients. It is 
particularly useful when symbols are used, since the names of the signals connecting the 
symbols usually do not match the name of the signals, inside fee symbols. The Signal 
Connectivity Browser 3030 is preferably used in conjunction with the Signal Browser. In one 
1 5 embodiment a signal is selected in the Signal Browser from a context menu entitled Show 
Connectivity. The selected signal is highlighted, and its path is expanded in fee Connectivity 
Browser. 

[0163] In a preferred embodiment, A Design Rule Checker (DRC) option gives fee 

designer instant feedback on fee syntax and semantic correctness of fee created MAGIC-C 
20 design. The editor supports the powerful feature of back -annotating errors directly on the 
graphical MAGIC-C constructs when clicking on an error message in fee IDE message 
window. 

[0164] As illustrated in FIG. 3 1 , A Library Browser is preferably included, as part of 

fee Design Browser Window. Using this browser, a designer can explore different libraries that 
25 are currently opened in fee design, and inspect which Symbols, Processes and Blocks they 
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contain. By left-clicking on a Symbol, Block or Process, the construct can be opened directly 
and edited 

[0165] A library project manager is also preferably included. In one embodiment, the 

library is actually a directory and not a file. A design project has a list of libraries (directories 
5 or folder), and a primary library (which is the project directory - the directory where the project 
file resides). Library paths are stored relative to the project directory when they are a child or 
sibling directory. An example of the Project Library Manager is depicted in FIG. 22. 

IV. Preferred GUIs for Debugging, Testing, and Signal Analysis 

[0166] One benefit of the present invention is that hardware and software may be 

10 debugged early in the design cycle and at an execution speed that is fast enough to permit 
development and debugging of software. Additionally, as described below, the test bench 
interfaces permit signals or variables to be evaluated at key locations or on a virtual test bench 
to confirm the proper operation of the system. This further increases the ability of a software 
development engineer to perform meaningful development and debugging of software early in 

15 the design cycle. When performing a co-simulation with a processor model, both the software 
and the hardware can be debugged simultaneously, with the additional benefit that the designer 
has foil observability into the peripheral hardware, i.e., internal signal can be analyzed which in 
a physical embedded system do not have pin-outs. The present invention also permits 
debugging in the hardware domain. Referring to FIG. 34C, hardware breakpoints 3900 can be 

20 associated with individual graphical constructs. The simulation can be stepped to individual 
hardware breakpoints 3900 or single-stepped through the command flow of the hardware FSM. 
Thus, this permits a form of debugging in which single-stepping can be performed in the 
hardware domain, while the hardware is fully operational using the FSM graphical debugger as 
part of the IDE. A conventional software debugger (e.g., an industry standard such as the 

25 XRAY from Mentor Graphics Corporation of Wilsonville, Oregon) can be used to control the 
software execution (e.g., can be used to select the placing of software breakpoints and to 
inspect and modify the program stack, registers, and memory). 



49 



WO 01/95161 



PCT/US01/17873 



[0167] The IDE preferably features a high-quality C++ code generator, hiding all the 

details of generating simulation code and giving the designer the freedom to concentrate on the 
system functionality rather than on the construction of an efficient simulation. It generates 
C++ code for the FSM description, compiles the generated code, and links in the simulation 
5 engine, resulting in a compiled code simulation executable. In another embodiment, the 
generated C++ code of each symbol can be compiled into a dynamic link library (DLL), 
capturing the behavior of that component At run-time, the loader in the simulation engine will 
load all of the DLLs of the components instantiated in the virtual prototype and start the 
execution. One benefit of using DLLs for components is that it facilitates the delivery and use 

10 of pre-packaged models of components. For example, a DLL may be used to reduce the 

compilation time of a hardware description. Another benefit of using DLL is that it facilitates 
storing IP models at a high level of security. The code generator generates a single C source 
file for every process or Block in a MAGIC-C specification. For a Process, the C source file 
implements the FSM using a skeleton build around a single 'switch (<state_name>)' statement 

1 5 . Every graphical construct is foreseen of a BREAKPOINT macro that will report the state of 
the FSM back to the editor (to be displayed during simulation) and to allow placing of 
breakpoints and single - stepping n the virtual hardware. In a running a simulation, test bench 
controls communicate directly with variables in the simulation. The simulation variables have 
functionality that allows them to communicate with graphical test bench controls. 

20 [0168] In one embodiment, the code generator generates a static table of each 

simulation variable. This table is used by the debug interface to find simulation variables. 
Additionally, referring to FIG. 46, the table may be used in the executing simulation to connect 
test bench controls and variables. In one embodiment, the test bench editor allows a user to 
select simulation variables for test benches from the static table and signal names from a list of 

25 signal names. 

[0169] In a preferred embodiment, debugging is fully graphical and interactive, and 

supports advanced features such as single-stepping, placing of breakpoints, and running for a 
specific number of cycles. Referring to FIG. 36, in a preferred embodiment breakpoints of 
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execution 3900 may be associated with individual graphical constructs 3980 of a FSM, 
providing the designer detailed insight as to what is going on in the system. Breakpoints can 
be placed even while the simulation is running. Concurrent FSMs can be debugged 
simultaneously by placing them in different debugging windows. 

5 [0170] Both single and multi-instance debugging of symbols is supported in which 

placing of a breakpoint inside a Ssymbol instance will either only stop at that specific instance, 
or at all the instances of the Symbol. In addition, a release build can be generated, which does 
not contain the debugging information and which is optimized for raw system simulation 
speed. 

1 0 [0171] The breakpoint and single step debugging support allows the designer to stop 

the entire system simulation at any point in either the software or hardware domain. When 
performing a co-simulation with a processor model, both the software and the hardware can be 
debugged simultaneously using the test bench, waveform viewer, and software debugger, with 
the additional benefit that the designer has full observability into the peripheral hardware, 

1 5 impossible to achieve when running the embedded software on a development board or on a 
FPGA. 

[0172] Simulation executables can be built to either run within the IDE or run stand- 

alone. The stand-alone mode can be used for (customer) demonstrations or for shipping IP 
hardware blocks to potential customers for evaluation. Batch mode running is supported in this 
20 mode, which can be combined with the use of scripting files to stimulate the simulation. 

[0173] Logging of simulation signals and variables is supported directly by the 

simulation engine, and can be selectively enabled/disabled on a per signal basis. Both logging 
to a file for off-line inspection and direct viewing in a separate Waveform Viewer tool, part of 
the IDE, are possible, as illustrated by Figure 33. File format options include ASCII and VCD 
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(V alue Change Dump). The latter option allows the generation of test bench stimuli from high- 
level system models to test and verify hardware blocks being developed as part of the system. 

[0174] In one embodiment, custom graphical test benches can be created using a Test 

Bench Builder tool and attached to a simulation, allowing the designer to customize the 
5 interaction with the simulator and observe specific specification variables. This tool allows for 
quick building of the human-machine interface of a system, e.g. the display and keyboard of a 
PDA, resulting in a natural way to interact with the simulation (rattier than be means of off-line 
scripting files). The full aspect of a system, including hardware, software and man-machine 
interface, can be modeled within the same environment. In one embodiment, test bench 
10 controls preferably use Microsoft's Component Object Model (COM) standard to 
communicate with the compiled-code simulation executable. 

[0175] As shown in FIG. 34A, in a preferred embodiment uses a drag-and-drop 

mechanism 3405 of test bench controls drastically shortening the time to create a test bench. 
Representations of commonly used test benches may be created and re-used. For example, a 

1 5 test bench may include a graphical representation of a keyboard 34 1 0, a graphical 

representation of a LCD text screen 3415, and a graphical representation of a waveform viewer 
3420. FIG. 34B is a screen shot of a virtual test bench having a keyboard, LEDs 3420, LCD 
screen 3440, ASCII display 3450, and IP packet monitor displays 3460. FIG. 34C is a screen 
shot of a virtual test bench that included graphical representations of buttons 3470, switches 

20 3475, an ASCII display 3478, and LEDs 3480. In a preferred embodiment, attaching the test 
benches to a simulation requires no re-compilation of the design. Moreover, test benches can 
be freely attached and detached from a simulation, depending on the designer's observation 
interest. A preferred test bench implementation uses the ActiveX technology developed by 
Microsoft. ActiveX® controls use COM technologies to provide interoperability with other 

25 types of COM components and services. Some preferred test bench controls include: signal 
buttons, LEDs, LCDs, Registers, Memory Viewers, a Keyboard, Text, and a Resource Meter. 
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[0176] In one embodiment, a Test Bench is a graphical interface representing a 

human/machine interface that may include a window portion representing a user input interface 
and a window portion representing a user display interface. The graphical interface 
representing a user input interface may include buttons and graphical objects representing a 
5 portion of a human/machine interface that allows a designer to send signals to the simulation 
by pointing and clicking on the button or object. For example, the test bench may include a 
graphical representation of a keyboard that a user may inject inputs to the simulation. The test 
bench may also include a window portion having a representation of a liquid crystal display, 
light emitting diode (LED), personal digital assistant (PDA), or other visual display of a 

10 human/machine interface. As one example, the user input interface may be used to control the 
operation of the simulation (e.g., Run, Step, and Break) and View and change the value of 
variables and memory. In addition, the simulation can directly interact with graphical objects 
to display text and graphics, such as a liquid crystal display (LCD) or screen for a simulation of 
a computer. Custom graphical objects can be created by the designer and used to extend the 

1 5 capability of the Test Bench Builder. 

[0177] A simulation may have more than one test bench. One approach is to make a 

separate user interface and debugging test bench. For example, if a designer was designing a 
cellular phone, the user interface would be similar to a phone (with all the buttons the finished 
product would have), and the debugging test bench would give access to internal parts of the 
20 system. 

[0178] In a preferred embodiment, Test Benches are created and edited in the Test 

Bench Builder tool in the IDE, and are added to the Design Browser as a part of a project. In a 
preferred embodiment, the simulation opens and displays each test bench window when 
running the simulation. A waveform viewer, as shown in FIG. 33 may be used to show signal 
25 occurrences of a variable on a time axis. 

[0179] FIG. 46 is a block diagram illustrating some of the interactions between the test 

bench and the simulation. A test bench loader is implemented as a dynamic link library (DLL) 
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linked to the simulation engine. It provides the entire GUI interface for a simulation (including 
the Simulation Cockpit main window). It runs in the same process as the simulation, but on a 
separate execution thread. When the simulation starts, the test bench loader is started and 
passes a pointer to the debug interface. It uses this debug interface for all communication and 
5 control of the simulation. When the test bench loader starts, it reads the project file from disk to 
get the names of the test benches. It then opens and reads each test bench file. In one 
embodiment the test bench is a MFC Document, using the document-view architecture. In one 
embodiment, the test bench editor and loader both use the same document and main view. The 
editor also places another transparent view on top of the main view to capture mouse and 
10 keyboard input to allow editing. The test bench controls are implemented as object linking and 
embedding (OLE) controls. They can be written with any development tool that can create 
OLE controls, such Microsoft Visual C++ using ATL (active template library). 

[0180] In a preferred embodiment, test bench controls implement OLE property pages 

and must provide property pages to allow the user to configure them. Referring to the flow 

1 5 chart of FIG. 47, in one embodiment, each test bench control implement has an interface to 
allow it to be used with the simulation using the debug interface. A control normally also 
implements one or more other interfaces that are used to communicate with the simulation. To 
send signals and get simulation variables, each control needs a pointer to the Debug Interface. 
This is done with a COM interface to the connection point. The test bench asks each control 

20 for it's connection point interface, and uses this to give the control a pointer to the debug 
interface. The control can then use this to connect to a variable and to send signals. 

V. Simulation Cockpit 

[0181] It is desirable that a user has a convenient means to monitor the progress of a 

simulation. Referring to FIG. 35, a simulation cockpit is preferably included. As indicated in 
25 FIG. 35, a user design specification is linked together with the simulation engine and a test 
bench loader into a single executable. In another embodiment, components are linked together 
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as DLLs, which the simulation loader loads before starting the execution of the simulation. 
The Simulation Cockpit will take care of the dynamic loading of the test bench control DLLs. 

[0182] In addition, the generated simulation executable preferably contains the 

necessary hooks to talk to the Simulation Cockpit, allowing to display the user with 
5 information messages on the status and progress of the simulation on the one hand, and 
displaying the user test benches in separate windows. 

[0183] The Simulation Cockpit preferably includes a message window to display 

information messages on the status and progress of the simulation. The Message Window 
displays textual information messages on the status and progress of a simulation, its 
1 0 connectivity state to processor models (i.e. in hardware / software co-simulation) and the 
opening of trace files. 

[0184] Both system messages and user messages are displayed in the same Message 

Window. System Messages are generated by the simulation engine which is linked in with the 
compiled user's MAGIC-C design specification. The following messages exist: (1) Trace file 
1 5 status messages, (2) Co-simulation (with processor model) Messages. User messages are 
messages generated by the user, using a specific print instruction inside his MAGIC-C 
specification. 

[0185] The simulation's test bench runs in the same process (but in a different thread) 

as the simulation, so communication between the test bench and a running simulation is very 
20 fast (the same as an indirect function call). 

VI. Security Of IP Blocks 

[0186] The present invention permits users to create models of hardware components 

and virtual platforms. It is desirable that users have a variety of security options that facilitate 
sharing virtual hardware components and prototypes with others. In one embodiment, the 
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high-level models developed are delivered as packaged binary DLL objects, protecting 
valuable IP. Ia a preferred embodiment, the IP author can select to make the internals of a 
design invisible (what the inventors' call "black box models") at a selected level of hierarchy in 
the specification. For example, an IP author of an IP hardware sub-system may desire that 
5 others only be able to view the IP component as a symbol having pins for coupling signals to 
other IP components (e.g., as a "black box") whose operation is to be understood with respect 
to the output signals it generates in response to input signals. Alternately, as another example, 
an IP author may desire that other be able to view an IP hardware component as symbols and 
blocks within symbols but not at the level of individual graphical constructs. Moreover, the 
1 0 visibility of the function of IP components at a selected level of hierarchy can be accurately 
controlled by choosing the location and number of test bench hooks. 

[0187] In addition, a user can specify a password for a specific design block or process 

allowing protect a person's or company's IP. Alternatively, this password can be used to 
provide access to only a limited set of (trusted) users, by handing out the key only to these 
15 users. 

[0188] In the context of virtual components or platforms exchanged with others, a user 

preferably is permitted to select layers of hierarchy that are non-viewable or non-editable. For 
example, a user may desire to provide a virtual prototype of a hardware component having a 
complex FSM representation and to provide access only to a symbol representation with virtual 
20 pins. 

VII. Network-Based Embodiments 

[0189] The present invention may reside on a computer system coupled to a computer 

network, such as a local area network, wide area network, Intranet, or Internet In a preferred 
embodiment, a persistent virtual channel is formed between the computer hosting the IDE and 
25 the client computer. In this embodiment, the simulation may be run on a high-speed network 
server. However, it will be understood that if the client computer has sufficient local resources 
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that the simulation may also be run on the client computer, e.g., files from the network server 
(e.g., instruction set accurate simulators) may be transferred to the client computer for use on 
the client computer. Alternately, an executable file of a virtual embedded system may be 
formed on the network server and sent to the client computer. 

5 [0190] Referring to FIGS. 5-8 and FIGS. 41-44, a preferred embodiment of the present 

invention is as a web-based service coupled to client computers either directly or indirectly via 
the Internet. In one embodiment, a network server of the web-based service runs the IDE 
application and the simulation, reducing the resources required by the client computer. 

[0191] As previously described, the IDE of present invention includes a design 

10 language at a high enough level of abstraction to permit models of embedded systems to be 
rapidly created and also has a sufficient execution speed to evaluate develop, and debug 
software on a virtual embedded system. The level of abstraction is also high enough that 
hardware implementation details required for the final end-use product are not required, which 
minimizes the risk associated with sharing or providing access to models of embedded system 
15 components, sub-systems, and platforms. Consequently, these features permit a class of new 
web-based services for embedded systems that were previously impractical. Some of the 
applications of a web-based service in accord with the present invention include: providing the 
IDE as a service miming on a high-speed server to facilitate the evaluation of IP blocks and the 
design of an architecture definition; generating virtual prototypes or virtual components that 
20 may be shared by user groups; aggregating IP from a plurality of suppliers into libraries and 
permitting a user to select and evaluate IP components or virtual platforms from the library; 
providing virtual test boards to market IP components; and providing a tool for a user or a 
vendor to create IDE files that may be used as executable specifications as part of a 
procurement process. 

25 [0192] A preferred client-server implementation of a web-based service may be 

understood with reference to FIGS. 41-42 and 44. Referring to FIGS. 41-42, in a preferred 
embodiment a persistent virtual channel 4105 (e.g., using a CITRDC METAFRAME 
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application, produced by Citrix Systems, Inc. of Fort Lauderdale, Florida) couples an 
application server 41 10 of an application computer form 4102 to a user's client computer 4104 
(e.g., using a JAVA applet). The persistent virtual channel 4105 is initiated responsive to the 
user initiating a HTTP request 4104 to a web server 4106. An authentication server 4120 is » 
5 preferably included to provide security. Referring to FIG. 41, the IDE may be coupled to a 
wide area network (WAN), local area network (LAN) or intranet. In an intranet, LAN, or 
WAN environment only minimal security measures may be required to limit access to 
authenticated users. However, for a web-based service, the network topology across which the 
data traffic between client and application server, and between client and web server preferably 

10 has firewalls 4205on both sides of the Internet, as depicted in Figure 42. A Secure Socket 
Layer (SSL) encryption on top of the HTTP protocol for the web server to/from client 
communication is preferably used. Additionally, the persistent communication channel (also 
known as a "virtual channel") between the client computer and the application farm is 
preferably encrypted, such as by using a conventional 40-bit, 56-bit, or 128-bit standard 

15 encryption technique. A load balancing server 4140 is preferably used to balance the demands 
of multiple client user sessions. 

[0193] Figure 44 shows the architecture and software modules of a preferred 

embodiment supporting collaborative development and design project management. In one 
embodiment, there is a user repository 4405, library repository 4410, and design repository 

20 441 5. Each repository includes a memory for storing data, such as disk storage units. The 
embodiment of FIG. 44 may also be used for procurement and marketing. The user 
respository 4405 is a database for storing user profiles. The user profile data may include the 
name, account, password and other background information of a user along with user interests, 
sign-up date, and design projects of users. The Library Repository 4410 stores records for 

25 each embedded system design block (e.g., processor cores, hardware symbols, or hardware 
sub-systems) and groups the records into libraries. A block record may contain the directory 
location and name of the block for accessing the physical storage side of the repository. A 
library record contains the name of the library, owner information, creation date, description, 
but most important the list of sub-blocks it consists of. 
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[0194] The Design Repository 4415 stores existing virtual embedded systems that are 

created by vendors or embedded system designers. The designs are preferably stored using 
library elements. A design record may contain the name of the design, the owner(s) user 
information, creation date, description, list of team members - each with their permissions for 
5 the design - and the list of blocks the design uses. In addition, it contains a directory and 
filename(s) of the design, so the reference with the physical design files as stored on the 
storage entity in the design repository can be made easily. Note that the design repository file 
system accessible by the application server farm. The databases in the three repositories are 
preferably coupled to permit them to share information. 

1 0 [0195] A collaborative design manager 4430 is preferably included to facilitate the 

implementation of a project management environment, and may include features such as 
version control, locking of design (elements) being edited, and advanced editing permission 
control. The collaborative design manager preferably resides on the application server or the 
web-server 4480 and in one embodiment includes a library manager module 4450, a design 

1 5 manager module 4460, and a user authentication manager module 4470 on the web server side 
to a web server daemon 4490 (e.g., by a CGI interface) as conceptually depicted in Figure 44. 
Different technology options are available for this back-end implementation, JAVA servlets, 
CGI scripts (e.g. in Perl), Microsoft's Active Server Pages (ASP), possibly combined with 
COM and distributed component object model (DCOM) applications. The modules 4450, 

20 4460, and 4470 preferably interact with each other by means of function calls to each other, 
which permits them to work interactively to implement a particular function such as looking 
up a name from a list of names associated with a design so that the user authentication manager 
4470 can determine if access to a version of a design is appropriate. The library manager 
module 4450 is a module that maintains the libraries and the design blocks of the library. It 

25 preferably supports functions related to the creation, editing, deleting, moving of a design 
block/library, changing of attributes (e.g. user access and edit permissions), and locking of 
libraries / design blocks when a specific user edits a directory. Additionally, it preferably 
supports version control of design blocks and libraries. The User Authentication and Manager 
module 4470 preferably supports the function of authenticating users when they login into the 
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web site, providing infonnation on user information like team membership and user 
permissions, adding / deleting approved users, and changing the attributes or privileges of 
users. The design manager module 4460 manages the designs stored in the design library, and 
the files they consist of. In a preferred embodiment, designs can be added / deleted, attributes 
5 changed, and modification made to the privileges of users in the design team. In one 
embodiment, each design may be assigned an administrators), who controls the user 
privileges. 

[0196] The interaction with the application server farm occurs when a user wants to 

open one of his existing designs or wants to create a new design. The design management web 

10 pages on the client side will typically show all the user's design in a tabular format, listing 
basic info as design name, date create, date last accesses etc. When clicking on one of the 
design names in this table — which are also hyperlinks - will send a request to the web server to 
open the design. The HTTPD daemon forwards this address to the Design Manager module 
which consults the design database of find the ID/string as which the design is known by the 

1 5 application farm. This string is send back in the HTTP response by the web server, the client 
will pass this information as parameter to the JAVA applet, who will include this as a message 
when negotiating the setup of a new virtual channel with the application farm. The farm will 
accept the ID/string and start a new session, in which it will start the IDE with the design 
opened. Note that the application farm will fetch the design data from the design repository 

20 physical storage, as depicted in Figure 34. If desired, other elements that can be included for 
collaborative sharing include message boards and discussion threads per design, as well as e- 
mail between team members or the sending of notes, which further promote collaborative 
working. 

[0197] Referring to FIG. 8, one benefit of the present invention is that a user may 

25 create a virtual embedded system as a basis for the procurement process related to an 

embedded system instead of a conventional written description of the embedded system. The 
level of hierarchy of the hardware description may be set by the designer at a level appropriate 
for a particular good or service. For example, the level of hierarchy may be set at a part level, 
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e.g., with symbols or blocks representing parts shown. Alternately, the level of hierarchy may 
be set to assist a vendor understand a net component list. Test benches may be configured by 
the designer to show signals or interactions of interest to a vendor. Moreover, in one 
embodiment a designer may select software to be executed on the virtual embedded system by 
5 potential vendors. If desired, the virtual embedded system may be provided in a view-only 
mode. The virtual embedded system and its associated software thus serve as a functional 
executable specification in that a vendor may use the design window view of the hardware 
(e.g., as symbols of major parts) and use a virtual test bench to understand the function of the 
embedded system related to the good or service provided by the vendor. Referring to FIG. 8, 

10 a vendor may open up a design 860, view a part list 862, and observe the operation of the 
embedded system as a basis for a quote 864, such as a private RFQ 866 or a pubic RFQ 868. 
As one example, referring to FIG. 29 a virtual embedded system including an interrupt counter 
may be formed at level of hierarchy in which one or more of the symbols 2920, 2930 
correspond to parts required for the embedded system. A virtual test bench may be configured 

15 to interact with the simulation and reveal signals related to the operated of one of the parts. 
Consequently, a vendor accessing the virtual embedded system would have a functional block 
diagram appropriate for understanding the operation of a part and be able to execute the 
simulation to understand the function of the part in the embedded system. 

[0198] The virtual embedded system may be stored as an executable file or a set of 

20 component DLLs capable of running the simulation or as DLL to the simulation, although any 
conventional means for providing access to a simulation of the virtual embedded system may 
be used. A link to the executable file or the simulation may be provided in a variety of 
different ways, such as providing a link on a portion of a web site hosted by the web-based 
service from which a user may launch the simulation and examine the function of the 
25 embedded system (e.g., by using the test benches or waveform viewer). Referring again to 
FIGS 8 a web-based service may be used to invite sellers to provide a quote for a specific 
design, in a request-for-quote (RFQ) scenario. In a RFQ embodiment, an executable 
specification of an embedded system is created 805 by a user using the tools of the IDE as 
described above. In a public RFQ embodiment 810 a user published an RFQ to a bill board 
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that includes access (e.g., a link) to the design file. In a private RFQ embodiment 815, a user 
selects the vendors and sends the selected vendors the RFQ and access (e.g., a link) to the 
design. A user can then search for information on suppliers 813 from a user and supplier 
database 81 1 and then select 812 from specific suppliers to send an RFQ 814 via RFQ 
5 database 850. Vendors, for example, may post information on their capabilities and interests 
permitting a manual search. Alternatively, this process can be upgraded to an automatic match 
making, by using a matching engine 820, based on a selectable set of criteria. Vendor/seller 
profile data may be used to classify providers and create directories that permit automatic 
matching between buyers and sellers based upon a standardized set of criteria. In one 
10 embodiment, the provider of the web-based service can take an active roll in rating the 

different sellers and service providers, based e.g. on their history, track record and the user 
feedback. This rating can be used as an (additional) input for the match making. The matching 
making engine would be fourth software module (not shown in FIG. 44), which would interact 
with the web-server, the User Manager and the Design Manager modules. 



1 5 [0199] In another embodiment, a bidding board 840 permits bids to be placed on 

designs. For example, a seller may review a board category 869 of a bidding board 840 for 
designs that they want to receive a RFQ on. In another embodiment sellers and vendors can 
subscribe 868, 872 to certain bidding boards (e.g., by category), and receive an automatic 
update (e.g., by e-mail notification or by a personal message box hosted by the web-service), 

20 whenever a new bidding opportunity is posted on the bidding board. A bidding board can be 
implemented as a database element, acting as a container for different bidding board listings, 
each pointing a single design or sub-design. In addition, it may contain the bidding history (i.e. 
the bids made, with all their attributes, including price, description and deliverable dates. 

[0200] Note that other information desirable for a RFQ or a bid may also be associated 

25 v with a simulation. For example, additional annotations for the design (e.g. power consumption 
and timing constraints, process technology preferences, deadlines) may be associated with a 
design. Additionally, a virtual embedded system may be used for an RFQ or bid for only one 
sub-system or component of the embedded system. Any conventional web-based method on- 
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line mechanism may be included for a seller to collect, overview, select and accept submitted 
quotes. 

[0201] Referring to FIG. 6, one application of a web-based service is as a web-site for 

the of evaluation IP components A web-based service permits access to virtual embedded 
5 systems and IP blocks to a large potential audience at a low incremental cost and with minimal 
support. For example, the virtual embedded system may be a simulation of an evaluation 
board for evaluating a processor core that is uploaded 650 by an IP vendor to the web-hosted 
service. For this embodiment, the virtual embedded system eliminates the need of a processor 
core vendor to send physical evaluation boards to prospective customers. Providing access to a 

1 0 virtual embedded system may be used to replace the traditional practices of sending of data 
sheets and physical evaluation kits, boards, or samples to prospective customers to evaluate an 
IP component of an embedded system. Instead, access is granted to prospective customers to 
on-line virtual prototypes of the vendors 5 offering. With these prototypes, the vendor can 
demonstrate the competitive edge of his offering by a real experience of the product by 

15 potential customers. In this embodiment, a vendor creates a virtual embedded system for the 
electronic system a vendor wants to market, (e.g., using the graphical design language 
described above) having instruction set simulators and "live" test benches of a human/machine 
interface to interact with the simulation. The virtual protototype is hosted on an application 
server (farm), accessible through the Internet network. The virtual prototype is made 

20 accessible to customers by publishing a web page or hyperlink, which can execute the 

prototype on the application farm. Prospective customers are allowed to inspect and navigate 
the virtual prototype in their browser, by starting the IDE from their browser to run on the 
application farm. As described below in more detail, a walkthrough function may be included 
to describe the attributes and function of virtual embedded system. 

25 [0202] Referring to FIG. 6, in a preferred embodiment of an evaluation service, a user 

may search 652 BP and platform libraries for potential suppliers. A user may select 656 
individual IP elements 636 or a complete virtual platform including a desired IP components 
and other components of a virtual embedded system from a library of virtual evaluation 



63 



WO 01/95161 



PCT/US01/17873 



platforms 638. The user can then customize the virtual platform, such as by adding or 
configuring virtual test benches 640. If desired, the user can modify one or more components 
of the virtual platform, such as hardware component, using the DDE. In a preferred 
embodiment, the user can store a customized virtual platform 642 for later use. The user can 
5 then upload benchmark software 660 to evaluate the operation of the embedded system. The 
evaluation process may include the use of the virtual test bench, debugger, and profiling data 
associated with the instruction set simulator of the target processor. The user may then run the 
benchmark software 662 on the customized virtual platform and evaluated its performance 
using the virtual test benches and/or software tools 644. This permits the user to select 
10 suppliers 664. 

[0203] One benefit to vendors is that a web-based service for marketing IP using virtual 

embedded systems can include web-based usage tracking and reporting 646. Moreover, user 
selections from the library of IP elements 636 and virtual platforms 638 may also be recorded 
to form market intelligence data. Mechanisms for usage tracking and reporting may include 

1 5 access statistics, traffic and user profile and demographics of the traffic to the platform 

offering, customer feedback, clicking-through statistics on advertisements posted on the web- 
site, and design leads of registered users. This report can be in printed or electronic format, the 
latter allowing it to be sent out by -mail directly. Standard web statistic gathering techniques, 
amongst others using a combination of web server logging, cookie placement on the client 

20 computer, and user profile data collected during user registration and web analysis programs 
can be used. For example, statistical techniques may be used to determine popular virtual 
platforms and/or modification to platforms. Thus, in addition to the low incremental cost of 
using virtual prototypes as a marketing tool for IP blocks, a vendor of IP components may also 
acquire valuable marketing data at a low incremental cost One way that an IP vendor can use 

25 data on on-line usage is to determine processor cores and hardware peripherals that user's 
desire in reference evaluation boards. For example, an IP vendor could provide a virtual 
reference evaluation board and track how users modify the hardware peripherals to provide 
feedback useful for creating new virtual reference evaluation boards. Another way that an IP 
vendor can use data on on-line usage is to determine market trends, i.e. use data on the 
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interaction of users with the hosted IP components as an indicator of market trends. For 
example, a web-based service may have a library of IP components that includes a variety of 
different types of processor cores (e.g., for different embedded system applications) and/or 
models of hardware components. Virtual test boards for the different IP components may also 
5 be included in the library. Data on which IP components and virtual test boards are selected 
for evaluation by users may be used as marketing data for predicting future demand. 

[0204] Referring to FIG. 7, another aspect of the present invention is that it provides a 

way for two parties to share an executable functional system specification from which two 
parties may agree (sign off) to the design specification or otherwise coordinate their efforts. 

1 0 One problem in conventional embedded system design is reaching agreement on a high-level 
design specification that coordinates and binds the efforts of different groups. The groups may 
be in house (e.g., a hardware group) or more commonly, it may include external vendors, such 
as hardware suppliers (e.g., memory providers) and silicon fabrication companies. 
Conventionally, the documentation of a paper specification upon which different groups can 

1 5 sign off is a time consuming process, particularly if documentation for several different 

versions of a design need to be created. Using the present invention, a virtual prototype 704 
can be used to replace paper specifications typically used to this process, by an executable 
functional; specification. Existing blocks can be put in on-line libraries accessible to be used 
by the specifying party to compose and configure his system, or to be modified to make them 

20 custom for his application. Non-existing blocks can be created on-line in the IDE from scratch. 
In all cases these models serve as medium to communicate between specifiers and 
implementors and to sign off 395 on behavior of the system, sub-system, IP or SOC before the 
implementation starts. Appropriate test benches may be included for interacting with the 
system at a desired level of hierarchy. 

25 [0205] Referring again to FIG. 7, in one embodiment of the present invention, an 

executable specification may be used to facilitate the collaborative development of electronic 
systems, sub-systems, IP and SOCs between geographically distributed user groups. For 
example, an embedded system project may include engineers who work in different divisions 
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of a single company or be a collaborative effort of several companies and/or subcontractors 
(e.g., an embedded system project with design groups in Silicon Valley and in Washington 
state). Conventionally, collaborative development of embedded systems has been hindered by 
communication problems and by the need of software developers for convenient access to 
5 physical prototypes to develop software. In accordance with the present invention, a web- 
hosted virtual prototype may be used as a communication vehicle/means for communicating 
information between different design teams, documenting designs, and coordinating design 
efforts. As one example, a virtual prototype may be made accessible to a geographically 
distributed design team by publishing a web page or hyperlink, which can start the virtual 

1 0 prototype software on the application farm. The design team members may select and open of 
libraries they want to use, and create their own libraries, with privileges they select. Design 
team members may be allowed to compose their own virtual prototype by instantiating existing 
blocks from the library, and to inspect, to navigate and to configure, and to customize these 
blocks. They may also create new blocks using the on-line virtual prototyping IDE. The 

15 design team members may be allowed to store and share with other design teams these newly 
created prototype designs on-line, e.g. on an on-line design repository file server. The design 
team members may be allowed to interact with a live model of the system, by executing the 
prototype on the application server farm and interacting with it through a desktop browser. In 
one embodiment, a design sharing and revision control mechanism permits a design team 

20 member to selectively share parts of the prototype or the full prototype with a list of other users 
he can select. The sharing can happen by sharing the design, test bench and result files or by 
transferring a hyperlink (possibly with a password) to the virtual prototype to the selected 
users. Another benefit of hosting a virtual prototype as a web-based service is that software 
developers have access to the most recent updates to the virtual prototype. Since the present 

25 invention permits early software development 352, continued software development 354, and 
early software integration 358 to be performed using a virtual prototype, the delays associated 
with shipping prototypes (or hardware emulators) between different teams is eliminated. 
Using the present invention one virtual prototype (or sub-versions thereof) may be shared by a 
comparatively large number of hardware or software developers, which facilitates collaborative 

30 development of geographically dispersed teams having a large number of members. 
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[0206] Referring again to FIG. 7, a benefit of using a web-based service for 

collaborative development is that the virtual prototype may be used by geographically 
distribute hardware developers and geographically distributed software developers. As 
previously discussed, the virtual prototype 704 permits: (1) the ability to start the development 
5 of embedded software early, and to develop the software concurrently with the hardware, 
promoting shorter design cycles, because of this concurrent engineering; (2) integration of 
(low-level) software with the hardware can happen before actual physical hardware is 
available. A web-based embodiment provides the further advantage that the simulation can be 
run on the server-end using a high speed computer. 

1 0 [0207] As previously described, in one embodiment of a web-based service a user may 

upload software for execution on a virtual embedded system via the Internet from a client 
computer. This allows software developers to interact with a live model of the system, by 
executing and debugging the software on top of the virtual prototype on the application faim 
and interacting with it through a desktop browser. The on-line infrastructure to compile, link 

1 5 and load the user's embedded software can be implemented in different ways. A preferred 
technique is to run the software development tool suite of the target processor in the same 
CITRIX METAFRAME session on the application server farm as the virtual prototyping 
environment. This will cause the software tool chain to be directly available in the 
METAFRAME, with minimal effort to adapt the software development tools. Two additional 

20 features are provided, namely the upload and download of source and object code to the users 
desktop (which both can be implemented with a transparent FTP connection). The upload will 
allow users to type in source code on their desktop first, and is especially useful for existing 
code, like e.g. benchmarks, which a user might want to execute on a new processor. The 
download allows users to locally store the source code they have typed in the METAFRAME 

25 window. 

[0208] In one embodiment, a walkthrough may be created for a platform that is an 

interactive presentation of the platform to the user. A walkthrough may be created for any 
virtual platform, although in one embodiment of a web-bases service a walkthrough is 
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included to explain the operation of a virtual evaluation platform 638 or IP component 636. 
FIG. 48 is a block diagram of an embodiment including a content viewer 4802, walkthrough 
content 4805, and an interface 4810 to a platform 4820. It performs a function similar to a 
person presenting a platform to the user. A walkthrough may be build from conventional web- 
5 based technology. The user navigates the walkthrough as a small web site tailored for the 
platform and audience. The walkthrough can have many pages. Each page can present any 
web content supported by the target browser. In addition, walkthrough pages can interact with 
and control programs outside the walkthrough, such as the modeling and simulation tools. A 
walkthrough provides a means for the platform designer to communicate the function, 

1 0 capabilities, and significance of a platform to the user. The walkthrough is a software 

application that displays web page content to the user, and allows the user to interact with a 
platform. In one embodiment, the walkthrough includes a content viewer, walkthrough 
content, and interface components that provide the link between the walkthrough content and 
the virtual platform that allows the walkthrough to interact with the platform. The interface 

1 5 components are generally custom pieces of software (such as an Active X control) that can be 
used by all walkthroughs. The content viewer may be any conventional content viewer, such 
as the HTA (an HTML application which is a web-page having an HTA file extension) or a 
web browser that supports the interface components and walkthrough pages, that can be used 
to display the walkthrough. 

20 [0209] As one example, the walkthrough may demonstrate setting a breakpoint in the 

simulation and running to that breakpoint. The interface component provides the mechanism 
for the walkthrough to set the breakpoint and run the simulation. The walkthrough content 
may be interactive, using scripting technology to interact with both the user and the simulation. 
The interface component can provide bi-directional communication between the walkthrough 

25 content and the rest of the platform. The walkthrough content can contain ActiveX controls like 
graph displays, integer register viewers and others. 

[0210] FIGS. 49A-49J are illustrative screenshots of one example of an interactive 

walkthrough used as a tutorial. FIG. 49A shows content introducing a tool known as a 
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"SuperQuick Calculator." Each page of the walkthrough 4902 may include a control, such as a 
"next" link 4901 to navigate the walkthrough. The content 4902 may be displayed next to a 
design window. Referring to FIG. 49B, the walkthrough may encourage a user to interact with 
a design 4920 in the design window 4904, such as by clicking upon a symbol 4925. As shown 
5 in FIG. 49C, a graphical application may be included to permit portion of the design window 
4904 to be outlined 4905 or arrows 4906 added to connect the content 4902 with portions of 
the design window. FIG. 49D is an example of design window opened to reveal a lower level 
of hierarchy, such as the graphical constructs of a FSM, by pressing upon a link in the 
walkthrough content In one embodiment, JavaScript in the Walkthrough is configured to call 

10 on an ActiveX control contained in the header of the Walkthrough HTML page. The ActiveX 
control then communicates with the IDE (e.g., using a COM technique) to request the design at 
the selected level of hierarchy. FIG. 49E shows a walkthrough content describing the 
operation of a virtual test bench that is a calculator. FIG. 49F is an example of a walkthrough 
page explaining how the virtual test bench may be used as human/machine interface to interact 

15 with a simulation. In the illustrative example, a user may click upon a button of the virtual test 
bench to input a number or command. The resultant "60" is displayed as a result of the user 
clicking upon the following buttons in order: "1 ", "2", "X", "5" "=" (representing the equation 
12x5 = 60). The "equals" button is shown highlighted since it is the last button in the 
sequence that the user clicks upon. The test bench page may be implemented as a HTML page 

20 with an ActiveX control having JavaScript in the HTML configured to permit communication 
with a running simulation. 

[0211] Note that FIGS. 49A-49F present a user with a high level representation of the 

function of a system (here a calculator). If desired, FSM implementation details and debugging 
interface may be provided to a user, along with interactive walkthough content FIG. 49G is an 
25 example of an interactive walkthough page explaining how a breakpoint of execution may be 
associated with a graphical construct. FIG. 49H is an example of an interactive walkthrough 
page explaining how a simulation may be executed until it stops at one of the breakpoints 
associated with the command flow of the FSM reaching the breakpoint. As shown in FIG. 
49H, in a preferred embodiment, a stop symbol 4980 is used to represent a breakpoint of 
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execution and is associated with a graphical construct 4982 of a FSM 4995 representation of 
hardware using an arrow symbol. 4984. FIG. 491 is an example of a walkthrough content page 
explaining how a breakpoint of execution may be associated with a task block representing a 
simulation variable "acc " The arrow in the process diagram indicates the current execution 
5 point, as the simulation has stopped on a breakpoint of execution. FIG. 49 J is an illustrative 
screen shot demonstrating the communication of the test bench with the simulation. In the 
example, the test bench displays the value of the simulation variable "acc." Whenever "acc" 
changes in value in the simulation, the change is displayed on the test bench. 

[0212] An interactive walkthrough can be used in several different ways. In one 

10 embodiment, an interactive walkthrough is used as marketing tool. An interactive walkthough 
may be used to provide an interactive guided tour of an electronic system, sub-system, or IP 
component As one example, content may be created to explain a feature of the virtual 
platform while the interface to the platform may be used by the user to observe an active 
simulation of the platform. 

15 [0213] FIGS. 50-55 are screen shots showing examples of an on-line embodiment. 

Referring to FIG. 50, a design manager may display a list of designs a user has stored in the 
design repository, such as design name, creation date, edit dates, or a description of the design. 
Referring to FIG. 51 , a design creation wizard 5102 may request 5 105 a user to provide a 
design name 51 10 or design description 5125. In one embodiment, a user is given the option 

20 to clone (copy) a pre-existing virtual embedded system from the design repository as the basis 
for a new design. Referring to FIG. 52, the design creation wizard 5102 preferably permits a 
user to browse and select IP components. 5202. In one embodiment, a user is permitted to 
select components 521 5 from a library repository. In the example of FIG. 52, the components 
5215 in the library may include a MIPS processor, a LCD controller, and a GPIO peripheral. 

25 The user is preferably provided with a toolbox 5230 to select components for use in a platform. 
In the illustrative example, a user has selected as IP components 5240 a general purpose 
input/output controller (GPIO), a LCD controller, and a MIPS32kc microcontroller. 
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[0214] As shown in FIG. 53, a browser window 5305 may display a list of the IP 

components and other design information, as described above. In the illustrative example of 
FIG. 53, a user has selected a processor simulator corresponding to a MIPS processor 53 10 and 
a GPIO controller 5320. The user may then compose an embedded system using the IP 
5 components in the BP toolbox as starting point. If a suitable IP component for a particular 
application does not exist in the library repository, a user may create a FSM model of the 
component. The embedded system design may be completed by making appropriate 
connections of signals. Referring to FIG. 54, a user may then be presented with the option 
5405 to upload software for execution on the virtual embedded system. The uploaded file 

1 0 executable binary file for the target processor (i.e., the processor selected for the embedded 
system). In an alternate embodiment, the uploaded file may be a source file for the target 
processor, which may be converted into an executable binary file by the service provider. 
After the software is uploaded, the user may select to run the simulator. As shown in FIG. 55, 
in one embodiment a user may then be presented with a window showing a test bench 5510, a 

1 5 software debugger window 5520, with the embedded system design 5530 shown in the 
background. 

[0215] While one preferred implementation of the present invention is as a web-based 

service, it will be understood that the IDE of the present invention may be used as stand-alone 
application running a simulation on a local computer or local network computer. For a stand- 

20 alone embodiment, the IDE may be stored on a computer readable medium (e.g., a compact 

disc (CD) along with other IP components (e.g., processor cores) for use with the IDE. Thus, it 
will be understood that the IDE may be used in off-line embodiments. Additionally, it will be 
understood that while the Internet is an especially efficient communication medium that other 
communication methods may be used to exchange data files. In particular, some of the 

25 functions of a web-based service may be emulated by using computer readable medium to 

exchange data files. As one example, the IDE may be stored on a computer readable medium, 
such as a compact disk (CD), along with one or more ISA processor cores. An embedded 
system designer would then couple the computer readable medium to a local computer system 
to use the IDE to design an embedded system. As another example, the IDE of the present 
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invention may be used to form virtual platforms representing evaluation boards. The virtual 
platforms may then be stored on a computer readable medium (e.g., a CD) and provided to 
embedded system designers for executing a simulation of the operation of the virtual evaluation 
platform. As still another example, a virtual prototype of an embedded system may be created 
5 using the IDE of the present invention and stored on a computer readable medium (e.g., a CD) 
and the computer readable medium shipped to another party for understanding the operation of 
the embedded system, e.g., for collaborative development of geographically dispersed teams or 
for procurement of a good or service related to the embedded system. Moreover, it will be 
understood that some of the functions of a web-based central service may be emulated using e- 
1 0 mail between individual computers or network servers. As one example, an embedded system 
designer may send a link to a data file of a virtual prototype stored in their network server to a 
vendor. 

[0216] Moreover, while particular embodiments and applications of the present 

invention have been illustrated and described, it is to be understood that the invention is not 
1 5 limited to the precise construction and components disclosed herein and that various 

modifications, changes and variations which will be apparent to those skilled in the art may be 
made in the arrangement, operation and details of the method and apparatus of the present 
invention disclosed herein without departing from the spirit and scope of the invention as 
defined in the appended claims. 



20 
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CLAIMS 



What is claimed is: 



1 . A computer system for simulating the operation of an embedded system 
using a software application residing in the memory of a computer, comprising: 

5 a design application configured to form a hardware specification of an 

embedded system, the design application including: 

a design language having at least one graphical symbol adapted to form 
a finite state machine (FSM) representation of electronic hardware, each graphical symbol of 
the design language having a graphical portion and a user-definable textual portion defining 
1 0 the behavior of the graphical symbol, 

a library including at least one instruction set accurate simulator for 
simulating the behavior of a target processor core having at least one memory read pin, at least 
one write memory pin, and at least one interrupt pin, 

a graphical user interface adapted to permit a user to select an 
1 5 instruction set accurate simulator of a target processor core and to form a FSM representation 
of a hardware component in the design language, and 

a configuration interface for coupling memory read/write signals and 
interrupt signals of the instruction set accurate simulator to corresponding signals of a the 
hardware component; 

20 a test bench builder for generating a graphical representation of at least one 

interactive test bench and for selecting signals or variables to be coupled to a graphical 
representation of a user interface for each interactive test bench; 
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a software debugger including a debugging interface for associating a 
breakpoint of execution a graphical symbol of the finite state machine representation of the 
hardware component; 

a graphical database and a behavioral database coupling data associated with 
5 the hardware description to a code generator; 

a compiler for compiling the output of the code generator into an object file of 
the hardware description; 

a discrete event simulation engine configured to execute the object file of the 
hardware description; 

10 a first API interface adapted to couple the discrete event simulation engine to 

each of the interactive test benches; 

at least one API interface adapted to couple the discrete event simulation engine 
to the instruction set accurate simulator of the hardware description; and 

at least one API interface adapted to couple the instruction set accurate 
1 5 simulator to a software debugger, the software debugger configured to load at least one binary 
program code compiled for the target processor. 

2. The computer system of claim 1, wherein the debugging interface is 
configured to permit the at least one compiled binary program code to be stepped to the break 
points of execution. 

20 3. The computer system of claim 1, wherein the design language is an 

adaptation of the specification and description language (SDL). 
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4. 



The computer system of claim 1, wherein the computer system has a 



simulation speed selected so that the software application executes at a rate greater than one 
million instructions per second. 

5. The computer system of claim 1, wherein the computer system serves as 
5 a hardware emulator and has a simulation speed sufficient to boot an embedded system 
operating system is less than one minute. 



coupled to a server of a computer network. 

7. The computer system of claim 6, wherein the computer network is 
10 selected from the group consisting of: a wide area network, a local area network, an Intranet, 
an extranet, or a computer network coupled to the Internet. 



coupled to the computer system by a network connection. 

9. The computer system of claim 6, further comprising: a design repository 
1 5 coupled to the server adapted to store a design specification for each of a plurality of 

embedded systems, each design specification including sufficient information to generate the 
hardware specification for the embedded system. 

10. The computer system of claim 9, further comprising a matching engine 
coupled to the design repository for associating metadata with each design specification and 

20 matching vendors to the stored design specifications based on the metadata. 



6. 



The computer system of claim 1, wherein the computer system is 



8. 



The computer system of claim 6, wherein a client computer may be 



1 1 . The computer system of claim 9, wherein each design specification 
includes at least one design specification source file configured to permit the hardware 
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specification to be viewed in the design language and at least one executable file to run a 
simulation of the embedded system that includes at least one of the interactive test benches. 

12. The computer system of claim 9, wherein each design specification 
includes at least one dynamic link library (DLL) that may be loaded by a loader executable to 

5 permit the design specification to be viewed in the design language and to run a simulation of 
the embedded system that includes at least one of the interactive test benches. 

13. The computer system of claim 9, further comprising: a design manager 
configured to control access to the design specifications stored in the design repository. 

14. The computer system of claim 6, wherein each design specification 

10 includes a design specification source file to describe each hardware element system, a file for 
each instruction set simulator of the embedded system, and a dynamic link library to execute 
the design specification. 

15. The computer system of claim 9, wherein the server is coupled to the 
client computer via the Internet. 

15 16. The computer system of claim 1 5, further comprising: an on-line 

bulletin board coupled to the server for a user to post a design specification. 

17. The computer system of claim 16, wherein the bulletin board is a 

bidding board. 



18. The computer system of claim 9, further comprising: content and a cc 
20 viewer configured to interactively explain to a user at least one attribute of a selected embedded sys 
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19. The computer system of claim 1, further comprising: a walkthrough 
application including content and a content viewer configured to interactively explain to a user 
at least one attribute of an executable file of the hardware description of a selected embedded 
system. 

5 20. The computer system of claims 1 8 or 1 9, wherein the walkthrough 

application is configured to allow the user to control the operation of a simulation of the 
embedded system through the content viewer. 

2 1 . The computer system of claim 20, wherein the embedded system 
includes a processor core and at least one reference hardware peripheral for evaluating the 

10 processor core. 

22. A computer-implemented method for assisting a user to evaluate at leas 
component of an embedded system, the method comprising: 

forming a virtual embedded system including an instruction set accurate 
simulator of a target processor core coupling read, write, and interrupt signals with a finite 
1 5 state machine (FSM) simulation of at least one hardware element; 

coupling a virtual test bench emulating a human/machine interface to the virtual 
embedded system, the virtual test bench having a graphical user interface adapted to interact 
with the virtual embedded system; 

receiving from the user a binary program code of a software application 
20 compiled for the target processor core; and 

responsive to a request from a user, loading the software application and 
running a simulation of the embedded system. 
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23. The method of claim 22, further comprising: 



creating content for explaining the operation of the virtual embedded system; 

and 



responsive to a user request, providing the content as an interactive 

5 demonstration. 



24. The method of claim 22, wherein the virtual embedded system resides 
on a server and the method further comprises: 



forming a data connection between the server and a client computer, 



receiving command and data user inputs from a web browser residing on the 
1 0 client computer; and 



providing graphical display data of the simulation running on the server to the 
web browser residing on the client computer. 



25. The method of claim 24, wherein the server is a network server coupled 
to the client computer via the Internet and the method further comprises: 



1 5 monitoring the user's interaction with the virtual embedded system; and 



recording data associated with an interaction of the user with the virtual 
embedded system. 



26. The method of claim 24, further comprising: 
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forming a plurality of virtual embedded systems in a library; 

receiving a request from a user for a selected virtual embedded system; and 

recording data associated with usage of the selected virtual embedded system. 

27. The method of claim 26, further comprising: 
5 requesting the user to submit registration data. 

28. The method of claim 25, further comprising: 

providing each user with a graphical user interface to modify the virtual 
embedded system; 

monitoring modifications made by a plurality of users to the virtual embedded 

10 system; and 

determining a statistically popular modifications to the virtual embedded 

system. 

29. The method of claim 24, wherein the software debugger is adapted to 
load binary program code compiled for a target processor core and the method further 

15 comprises: 

responsive to a user request, loading onto the virtual embedded system a binary 
executable program file of a software application compiled for the processor core; and 
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displaying a simulation of the virtual embedded system executing the software 

application. 

30. The method of claim 22, further comprising: 

providing the user a graphical interface having a design language including a 
5 plurality of graphical symbols adapted to form a finite state representation of a user-defined 
hardware element that may be coupled to the virtual embedded system. 

3 1 . The method of claim 30, wherein the graphical symbols have a 
graphical portion and a textual portion with at least one of the graphical symbols including a 
textual portion adapted for the user to describe a behavior of the symbol. 

10 32. The method of claim 3 1 , wherein a user may input a text portion 

including at least one command written in the ANSI C/C++ language. 

33. The method of claim 31, wherein the design language is an adaptation 
of a specification and description language (SDL). 

34. The method of claim 22, wherein a plurality of virtual embedded 
1 5 systems are stored in a database, the method further comprising: 

responsive to a user request, selecting one of the virtual embedded systems for 

evaluation. 

3 5 . The method of claim 22 further comprising: 

forming content for the embedded system, the content including a at least one 
20 graphical control interface configured to interact with the simulation of the embedded system: 
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responsive to a user request displaying content associated with the embedded 

system; and 

responsive to a user input to the graphical control interface, displaying an 
interaction with the simulation. 

5 36. The method of claim 35, wherein the content is a tutorial of the 

embedded system. 

37. In a computer system having a graphical interface and a design language 
for forming a finite state machine (FSM) representation of a hardware partition of an 
embedded system, a method of designing an embedded system, the method comprising: 

10 forming a library of processors including an instruction set accurate simulator 

for each of the processor cores in the library; 

responsive to a first sequence of user commands, selecting at least one of the 
processor cores from the library as a target processor; 

responsive to a second sequence of user commands, forming a virtual 
1 5 embedded system including an instruction set accurate simulator of a target processor core 
coupling read, write, and interrupt signals with a finite state machine (FSM) simulation of at 
least one hardware element; 

responsive to a request from the user, loading an executable binary file of a 
software application compiled for the target processor; 

20 executing a simulation of the virtual embedded system running the software 

application; 
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responsive to a user request, displaying a graphical representation of the 
execution of the software on the virtual embedded system that includes a software debugger 
interface to debug the loaded software and a virtual test-bench having a graphical user 
interface adapted to interact with the simulation. 

5 38. The method of claim 37, wherein the design language includes a 

plurality of graphical symbols with each graphical symbol having a graphical semantic portion 
and a textual semantic portion. 

39. The method of claim 38, wherein the design language includes: 

a start object defining a starting point of the finite state machine at an 
10 initialization time, the start object having an output connector activated when the start object is 
initialized; 

a task object including a field for inputting computer code in the C language for 
defining a behavior of the task object and a connector port for coupling the task object to other 
objects; 

15 a state object for representing a state of the finite state machine; 

a decision object having an evaluation field for directing a flow of execution 
based on a result of an expression in the decision field; 

a signal-out object for sending a communication signal; 

a signal-in object for receiving a communication signal; 

20 a connector object for connecting control flow; 
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a symbol object having at least one user-definable pin connector and containing 
a block or process object; 

a block object for describing the behavior of one or more processes; and 

a process object for representing a finite state machine process. 

5 40. The method of claim 37, further comprising: 

storing the virtual embedded system as a design in a design repository coupled 
to a server, and 

providing access privileges to the design to a selected individual or group. 

41 . The method of claim 40, further comprising: 

10 responsive to a user command, providing access privileges to the design to a 

group of vendors. 

42. The method of claim 41, wherein the design is accessible from an on- 
line bidding board. 

43. The method of claim 41, wherein access privilege to the design are 
1 5 provided to a group of vendors selected by the user. 

44. The method of claim 40, wherein the design is accessible by an 
embedded system design team. 
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45. The method of claim 40, further comprising a design manager 
application, the method further comprising: 

permitting one or more members of a design team to select edit privileges of at 
least one version of the design. 

5 46. The method of claim 45, further comprising: 

permitting one or more members of the design team to load and execute a 
binary program exeucutable of a software application compiled for the target processor core 
onto the design. 

47. The method of claim 45, further comprising: 

1 0 providing version control and regulating editing access to maintain a consistent 

version of the design. 

48. The method of claim 37, further comprising: 

storing a plurality of virtual embedded systems in a library; and 

responsive to a user request, providing the user a copy of one of the virtual 
1 5 embedded systems stored in the library. 

49. The method of claim 38, further comprising the graphical user interface 
is configured to permit a a user to associate a breakpoint of execution with a graphical 
symbol, the method further comprising: 
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responsive to a user input, associating a breakpoint of execution with a 
graphical symbol; 

receiving a request to debug software; and 

stopping the simulation responsive to a command flow of the FSM 
5 representation of the hardware element reaching the graphical symbol of the breakpoint of 
execution. 

50. The method of claim 49, further comprising: 

responsive to a user request, single-stepping the simulation to sequential 
breakpoints of execution in the command flow of the FSM representation of hardware 
10 elements. 

5 1 . The method of claim 49, further comprising: 

responsive to a user request, single-stepping the simulation by a pre-selected 
number of time units. 

52. A computer implemented method of embedded system design, the 
1 5 method comprising: 

selecting an instruction set accurate simulator of a target processor core; 

generating a virtual hardware component that is a finite state representation of 
at least one hardware component; 
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linking read, write, and interrupt signals of the instruction set accurate simulator 
of the target processor core with corresponding signals of the at least one virtual hardware 
component to form a virtual embedded system; 

coupling a virtual test bench to at least one signal or variable of the virtual 
5 embedded system to simulate a human/machine interface; and 

coupling a software debugger to the virtual embedded system that is configured 
to load and run on the virtual embedded system at least one binary program executable of a 
software application compiled for the target processor core. 



selecting the virtual hardware component from a library of virtual hardware 

components. 



53. The method of claim 52, further comprising: 



10 



selecting the target processor core from a library having a plurality of 
instruction set accurate simulators for a plurality of processor cores. 



54. The method of claim 52, further comprising: 



15 



55. The method of claim 54, further comprising: 



modifying the virtual hardware component. 



56. The method of claim 52, further comprising: 
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loading benchmark software in an evaluation phase of an embedded system 
project and running a simulation of the virtual embedded system executing the benchmark 
software. 

57. The method of claim 52, further comprising: 

5 loading binary program executables of development software compiled for the 

target processor core in a development phase of an embedded systems project and running a 
simulation of the virtual embedded system executing the development software. 

58. The method of claim 57, further comprising: 
debugging the development software using a software debugger. 

10 59. The method of claim 52, further comprising: 

storing the virtual embedded system as a design having at least one executable 
file in a design repository. 

60. The method of claim 59, wherein the design is stored on a server 
accessible to a user-group. 

15 61. The method of claim 60, wherein the user-group is a geographically 

distributed embedded system project team. 

62. The method of claim 59, further comprising: 

providing a version of the design to a vendor offering a good or service related 
to the virtual embedded system. 
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63. The method of claim 62, wherein the design is stored on a server and a 
vendor is provided access to the design via a network connection. 

64. A method of designing an embedded system, the method comprising: 

defining a system architecture of the embedded system; 

5 designing a virtual prototype of the embedded system having an instruction set 

accurate simulator of a target processor core coupling read, write, and interrupt signals with a 
finite state machine (FSM) representation of at least one hardware element; 

coupling the virtual prototype to a software debugger having a debugging 
interface and a virtual test bench having a graphical representation of a human/machine 
10 interface for interacting with the embedded system; 

developing at least one software application for the processor core; 

loading compiled binary program code of the at least one software application 
for execution on the virtual prototype; and 

initiating a simulation of the virtual prototype executing the at least one 
1 5 software application. 

65. The method of claim 64, further comprising: 

developing a hardware implementation using the virtual prototype as a 
functional specification describing a hardware partition. 

66. The method of claim 65, further comprising: 
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evaluating the operation of the embedded system executing the at least one 
software application; and 

responsive to a result of the evaluation, modifying a hardware or software 
component of the embedded system. 

5 67. The method of claim 64, wherein the step of defining the system 

architecture comprises: 

selecting at least one embedded system component for evaluation; 

forming a virtual evaluation platform including the selected embedded system 

component 

1 0 loading a benchmark software application for execution on the virtual 

evaluation platoform; and 

evaluating performance of the virtual evaluation platform executing the 
benchmark software application. 

68. A method of providing information to potential suppliers for procuring a 
1 5 good or service associated with an embedded system, the method comprising: 

defining a system architecture of the embedded system; 

designing a virtual prototype of the embedded system having an instruction set 
accurate simulator of a target processor core and a virtual hardware element that is a finite 
state machine (FSM) representation of a hardware element configured to couple memory 
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read/write requests and interrupt signals with the instruction set accurate simulator of the target 
processor core; 

coupling the virtual prototype to a virtual test bench having a graphical 
representation of a human/machine interface for interacting with the embedded system; 

5 publishing the virtual prototype as a functional specification from which a 

vendor may initiate a simulation of the operation of the embedded system. 

69. The method of claim 68, wherein the virtual prototype is stored on a 
computer readable medium and publishing the virtual prototype comprises sending the 
computer readable medium to a vendor. 

10 70. The method of claim 68, further comprising a network server, wherein 

the virtual prototype is published by posting the virtual prototype as a design hosted on a 
database coupled to the network server. 

7 1 . The method of claim 70, wherein the virtual prototype is published to a 
bulletin board of the database. 

15 72. The method of claim 7 1 , wherein the bulletin board is a bidding board. 

73. The method of claim 70, wherein the virtual prototype is published to a 
database having a matching engine. 

74. A computer-implemented method for a vendor to acquire information 
for the procurement of a good or service related to an embedded system project, the method 

20 comprising: 
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accessing a database of virtual prototypes of embedded systems, each of the 
virtual prototypes having a processor simulator, a finite state machine representation of 
hardware peripherals, and a virtual test bench emulating a human/machine interface for 
interacting with a simulation of the operation of the virtual prototype; 

5 instantiating an instance of one of the virtual prototypes; and 

evaluating the virtual prototype. 

75. The method of claim 74, further comprising: 

submitting a quote for a good or service related to the embedded system 
simulated by the virtual prototype. 

10 76. The method of claim 74, wherein the virtual prototype is configured to 

show a parts list. 

77. The method of claim 74, wherein the virtual prototype is configured to 
show a component net list. 

78. The method of claim 74, wherein the database of virtual prototypes is 
1 5 hosted on a network server accessible by a client computer. 

79. A computer-implemented method for evaluating at least one component - 
embedded system, the method comprising: 

forming a virtual embedded system including an instruction set accurate 
simulator of a target processor core coupling read, write, and interrupt signals with a finite 
20 state machine (FSM) representation of a hardware element; 
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coupling a virtual test bench emulating a human/machine interface to the virtual 
embedded system, the virtual test bench having a graphical user interface adapted to interact 
with the virtual embedded system; 

hosting the virtual embedded system on a network server accessible from a 
5 client computer via the Internet, 

uploading from the client computer a binary executable program file of a 
software application compiled for fee target processor core; and 

responsive to a request from a user, running a simulation of the operation of the 
virtual embedded system executing the uploaded software application. 

1 0 80. The method of claim 79, further comprising: 

forming content for explaining the operation of the embedded system; and 

responsive to a request from a user, sending the content to the client computer. 

81 . The method of claim 79, further comprising: 

responsive to a request from the client computer, forming a persitent data 
1 5 connection between the network server and a client computer, 

receiving command and data user inputs from a web browser residing on the 
client computer; and 

providing graphical display data of the simulation running on the server to the 
web browser residing on the client computer. 
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82. The method of claim 79, further comprising: 

monitoring the user's interaction with the virtual embedded system; and 

recording as marketing data at least one interaction of the user with the virtual 
embedded system. 

5 83 . The method of claim 79, further comprising: 

forming a plurality of virtual embedded systems in a library; 

receiving a request from a user for a selected virtual embedded system; and 

recording data associated with usage of the selected virtual embedded system. 

84. The method of claim 83, further comprising: 

1 0 requesting the user to submit registration data and associating the registration 

data with the marketing data. 

85. The method of claim 84, further comprising: 

providing the user a graphical interface having a design language including a 
plurality of graphical symbols adapted to form a finite state representation of a user-defined 
1 5 hardware element that may be coupled to the virtual embedded system; 

monitoring modifications made by a plurality of users to the virtual embedded 

system; and 
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determining a popular modification to the virtual embedded system. 

86. A computer program product for simulating an embedded system, the 
computer program product comprising: 

a computer readable medium: 

5 a processor simulator module stored on the medium having an instruction set 

accurate simulator for at least one processor core; 

a design application module stored on the medium for designing a virtual 
prototype of the embedded system having an instruction set accurate simulator of at least one 
processor core coupling read, write, and interrupt signals with a finite state machine (FSM) 
1 0 representation of at least one hardware element; 

a simulation engine module for executing a simulation of the virtual prototype; 

a software debugger module stored on the medium for a user to load compiled 
program code for execution on the virtual prototype; and 

a test bench module stored on the medium for forming a virtual test bench 
1 5 having a graphical representation of a human/machine interface for interacting with an 
embedded system prototype. 

87. A computer program product for providing information on the operation 
of an embedded system, comprising: 

a computer readable medium; 
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a hardware description of the virtual embedded system stored on the medium, 
the hardware description including an instruction set accurate simulator of a processor core 
coupling read, write, and interrupt signals with a finite state machine (FSM) represention of at 
least one hardware element; 

5 a simulation engine module stored on the computer readable medium for 

forming a simulation of the embedded system running a software application on the hardware 
description; and 

a test bench module stored on the medium for forming a virtual test bench 
emulating a human/machine interface to the simulation of the embedded system, the virtual 
1 0 test bench having a graphical user interface adapted to interact with the simulation of the 
embedded system. 

88. A computer program product for evaluating an embedded system, 

comprising: 

a computer readable medium; 

15 at least one executable file of a hardware description of a virtual embedded 

system stored on the medium, the virtual embedded system including an instruction set 
accurate simulator of a processor core coupling read, write, and interrupt signals with a finite 
state machine (FSM) simulation of at least one hardware element; 

a simulation engine module for running the at least one executable file as a 
20 simulation of the embedded system; and 
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a test bench module stored on the medium configured to form a virtual test 
bench emulating a human/machine interface to the virtual embedded system* the virtual test 
bench having a graphical user interface adapted to interact with the virtual embedded system 



5 
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// External interface 

extern_signal WR (unsigned int, unsigned int f 
unsigned int) ; 

extern_signal RD (unsigned int, unsigned int) ; 

extern_signal Write_Ack; 

extern_signal Read_Dat a (unsigned int); 

extern_signal CNTINTR (unsigned int); 

// Local variables 

signal start_clk; 

clock elk; 

bool clock_started; 

unsigned int LIMIT; //write register 
VS_int COUNT; 
//temp vars 

unsigned int data, width, addr; 
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Simulation to Test 
Bench Communication 

Now the simulation should 
be stopped on a task block. 
Click here to show it. 

A task block is C++ code 
that is executed as part of a 
simulation. This task block 

modifies the variable acc. 

On the test bench (click 
^jb> t0 show it) the 
number on the bottom 
displays the current value of 
acc. 

Now step once c^J) more 
while watching the test 

bench. That is all it takes to 
update the test bench! 



Previous.. 




Figure 49J 
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Simulation to Test 
Bench Communication 

Now the simulation should 
be stopped on a task block. 
Click here to show it. 

A task block is C++ code 
that is executed as part of a 
simulation. This task block 
modifies the variable acc. 

On the test bench (click 
<£^> to show it) the 
number on the bottom 
displays the current value of 
acc. 

Now step once more 
while watching the test 

bench. That is all it takes to 
update the test bench! 

Previous... Next 
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bJustGotOp = 0; 




wait_for_key 
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4995 



num_key_press(key_in) 




if(bJustGotOp) 
( 

acc_save = acc; 
acc = 0 

bJustGotOp = 0; 
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pText->Write("num"); 
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Done 
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Single Stepping 

Click this icon <&k> to 
bring the simulation to the 
front again. 

Now Click on a number key 
in the simulation so it will 
hit on a breakpoint 

Click here igJf to bring the 
Virtio Vie wer forward It 
should be stopped at the 
breakpoint. 

You can single step from the 
Viewer menu or toolbar, or 
this icon: 



Single step two times and go 
to the next page to see how 

the simulation 
communicates with the test 
bench. 

Previous... Next 



Figure 49H 



SUBSTITUTE SHEET (RULE 26) 



WO 01/95161 



PCT/US01/17873 



56/65 




Setting a Breakpoint 

To set a breakpoint, first 
check the viewer icon: 



to bring the Virtio Viewer to 
the front 

The simulation is still 
running, it is just behind the 
viewer now 

We will set a breakpoint on 

a Signal In construct 
Check here to show it. (the 
next click will remove the 
arrow). 

Set a breakpoint by right 
clicking on the Signal In, or 
by checking this stop icon: 



Previous... Next 
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Done 
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Running the 
Simulation 

Press the arrow button to 
start the simulation 



The simulation is a separate 
compiled executable, so it 

runs very fast. The 
simulation displays the test 
bench which now acts as a 
user interface for the 
simulation. 

Try clicking on some of the 
buttons and watching the 
number on the button. 

Click next and we will set a 
breakpoint. 

Previous... Next 
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HTML Test Bench 

This design has a test bench 

that provides a user 
interface to this design, click 
here to show the test bench. 

This test bench is HTML 
code with JavaScript that 
can interface with the 
runnning simulation. 

The test bench is a live web 
page. When the mouse goes 
over the button they 
up. 



Click next and we will run 
the design 
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For Help, press F1 



The Design 

To the left you see the 
Virtio Viewer 
First let's explore the design 

To make more room on 
the screen, first close the 

browser window 
(Show me - second click 
removes box)(Close it) 

The top level diagram(show 
diagram) only has one 
symbol (show symbol) 

Double click on the symbol 
or click here to show the 
symbol implementation. 
This is a process diagram 
(state machine) 3 that does 
all the work for this design 

Previous... Next 



Figure 49D 
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The Design 

To the left you see the 
Virtio Viewer 
First let's explore the design 

To make more room on 
the screen, first close the 

browser window 
(Show me - second click 
removes box)(Close it) 

The top level diagram(show 
diagram) only has one 
symbol (show symbol) 

Double click on the symbol 
or click here to show the 
symbol implementation. 
This is a process diagram 
(state machine) 3 that does 
all the work for this design 
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Test Bench: For each control 



Test Bench: Give Debug Interface pointer to Control 



Control: Ask Debug Interface to conncet to a simulation variable 



Debug Interface: Finds variable (by name) 



No 




Debug Interface: Asks variable for the interface that the control 
requested and gives interface to the control 



Debug Interface: Gives variable a chance to conncet to the control 



Variable: Asks control for any interface it wants 
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